7

Sitecore Admin will not present in CD server, how to get to know the Cache limit and usage in CD server.

In local environment, where CD and CM are available we'll use the below URL.

http://[domain]/sitecore/admin/cache.aspx

But is there any other way to check the CD server cache utilization?

Update:

The below link will provide information like how to disable the Sitecore capability in CD. So you can set appropriate 'Authentication' (may be Windows authentication ) and access the 'Sitecore' folder!

http://jondjones.com/learn-sitecore-cms/sitecore-developers-guide/sitecore-deployments/how-to-disable-sitecore-admin-from-your-content-delivery-servers

Improve this question

5 Answers 5

Reset to default
10

If you are using Sitecore 8.0 Update 3 upwards then a couple of new default processors were added to the Health Monitors to periodically dump the Cache Status and Rendering Statistics to files on disk. By default this process is run every 10 minutes, and they are run on the CD servers as well so you can use these files to check how your caches have been behaving.

From the Sitecore 8 Update-3 release notes:

Periodic dumping data from /sitecore/admin/stats.aspx and /sitecore/admin/cache.aspx pages to the file system has been implemented. New processors have been added to the pipeline. The location and format of the log file can be configured as part of the processor configuration. By default, dump files are stored in /diagnostics/health_monitor in the Data folder. (415409, 415411)

The specific processors are:

<healthMonitor>
    <!-- Dumps the information that the /sitecore/admin/cache.aspx page contains -->
    <processor type="Sitecore.Pipelines.HealthMonitor.HealthMonitor, Sitecore.Kernel" method="DumpAllCacheStatus">
      <dumpFile>$(dataFolder)/diagnostics/health_monitor/CacheStatus.{date}.{time}.html</dumpFile>
    </processor>
    <!-- Dumps the information that the /sitecore/admin/stats.aspx page contains -->
    <processor type="Sitecore.Pipelines.HealthMonitor.HealthMonitor, Sitecore.Kernel" method="DumpRenderingsStatistics">
      <dumpFile>$(dataFolder)/diagnostics/health_monitor/RenderingsStatistics.{date}.{time}.html</dumpFile>
    </processor>
</healthMonitor>

The processors simply read the caches and rendering statistics, create an HTML table of the values and then dump them in the folder location specified. The output is very similar to what you see when you visit /sitecore/admin/cache.aspx or /sitecore/admin/stats.aspx.

When tuning caches, particularly during performance or load testing you may want to record the statistics more frequently, which you can do by reducing the configuration setting to a more suitable value:

<!--  HEALTH MONITOR INTERVAL
       Specifies the interval between running the healthMonitor pipeline.
        Default value: 00:10:00 (10 minutes)
-->
<setting name="HealthMonitorInterval" value="00:10:00"/>

You can read more about this feature in this blog post which I previously wrote.

Improve this answer
4
  • 1
    Interestingly in 9.1 the <dumpFile> processors are not included OOTB. Only Log(Memory/Cache/Counter)Status is used which is nowhere near as verbose. I don't see an obvious reason for their removal as counters are written to the $(dataFolder)\diagnostics\counters folder. Appears the DumpAllCacheStatus proc can be added back in.
    – jrap
    Jun 27, 2019 at 15:01
  • 1
    @jrap I just checked on a 9.1 instance and these are still there and defined in /App_Config/Sitecore/CMS.Core/Sitecore.Diagnostics.config. It's in the <healthMonitor> pipeline.
    – jammykam
    Jun 27, 2019 at 20:43
  • 3
    I was looking at Sitecore 9.1.0 (Cloud) CD package and that config is disabled by default. It should be fine to enable that config though. Thanks for pointing me in the right direction!
    – jrap
    Jun 28, 2019 at 12:51
  • I think it makes sense to disable this by default. Generally, you want your CD servers to be as lean as possible, and logging stats just for the sake of logging stats does not make sense if you are not going to using them. In PaaS, since the servers are transient by nature, probably doesn't make sense to log them to disk either. Glad it you resolved it though.
    – jammykam
    Jun 28, 2019 at 13:11
3

If you aren't able to use windows authentication for some reason, I have implemented security for the Sitecore areas on CDs by using IP filterings and only allowing the local server IP address to access the pages.

This forces the user to be on the physical box (meaning they at the very least have RDP permissions, so hopefully are a trusted administrator) and can then access the Sitecore pages from there.

Improve this answer
1

Adding to the answer (Sitecore 10.*):

  • Go to the CD server and check the App_Data\diagnostics\health_monitor folder.
  • You will get their file named CacheStatus.20230412Z.141522Z.html where 20230412Z.141522Z is a time stamp. (Sitecore saves a copy of the cache.aspx page every ten minutes)

Note: In most cases you will get the file under the folder but if you cannot find the file then you need to enable it.

  • Go to the \App_Config\Sitecore\CMS.Core folder on CD server.

  • Verify that Sitecore.Diagnostics.config file is enabled or not.

  • Remove the .disabled extension of the file to enable it. (The configuration for the health_monitor folder is in this configuration patch.)

  • Verify your App_Data\diagnostics\health_monitor folder after 10 minutes, you will see the file below. (It previews from the Azure PaaS portal in the web browser) enter image description here

See the blog post for more details: Monitor and Tune Cache on CD Server

Improve this answer
0

The way I do my scalability settings is for CD servers where I need to access certain pages like cache page I implement the Windows auth and restrict all other pages by disabling anonymous.

So the answer would be to leave Windows auth enabled for the desired pages.

Improve this answer
0

Adding to @jammykam's reply, make sure that you have this hook enabled:

 <hook type="Sitecore.Diagnostics.HealthMonitorHook, Sitecore.Kernel">

This is included in the stock Sitecore.config file, but may be deleted by other patch files (e.g. DiagnosticsOff.config, installed by Sitecore Docker tools). This enables a Sitecore.Services.AlarmClock object to fire at the configured interval.

Improve this answer

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge that you have read and understand our privacy policy and code of conduct.

Not the answer you're looking for? Browse other questions tagged or ask your own question.