It's important to ensure that your cache sizes in Sitecore are appropriately sized for the load on your site. Too small and the cache will get evicted too often, hurting performance. Too big and you risk wasting server memory.
In this article, I give a quick overview of viewing cache usage using the standard Sitecore tools, before I then show what you can do using my LINQPad script.
Viewing Cache Usage
Sitecore XM\XP provides two options to view your cache usage:
an admin page (eg http://yoursite.com/sitecore/admin/cache.aspx
cache diagnostics files
The admin page is usually accessible on your CM environment and provides a single snapshot at the current point in time.
Enabling Diagnostics
The LINQPad script uses files generated from diagnostics logging. To enable diagnostics, you typically find the file:
\App_Config\Sitecore\CMS.Core\Sitecore.Diagnostics.config.disabled
and then rename it removing the ".disabled" part leaving you with:
\App_Config\Sitecore\CMS.Core\Sitecore.Diagnostics.config
Caution! This will trigger a restart of the environment!
It is not advisable to leave this enabled permanently as it does incur some performance overhead and disk space.
Viewing Cache Status Files
The default logging interval is 10 minutes, so about 10 minutes after the restart you should start seeing files created in the folder:
\App_Data\diagnostics\health_monitor\cache_status
If you are using an Azure App Service, you can access the folder via the Kudu console and download a zip of all the status files at once. Opening one of the files in a browser reveals something like this:
Shows the sizes of each cache within Sitecore. Things which annoy me: * not sorted alphabetically * current size is shown in different units from max size
Things which annoy me here are:
table is not sorted
the Size is not shown in the same units as MaxSize
each file provides just a snapshot of a point in time
Cache Tuning Objectives
Our goals when reviewing these files are to:
find any caches which are reaching 80% of the maximum size
find any caches which are consistently below 50% of the maximum size
For caches which are reaching 80% of maximum size, the recommendation is to increase by 25%.
For those which are consistently below 50% of the maximum size, the recommendation is to reduce by 25%.
Using the script
To avoid having to manually trawl through report files, I have written a small LINQPad script which parses the files and aggregates the data producing a summary table of results including min-max-average for count and size and a flag indicating if the cache requires adjustment along with the recommendation e.g. "Increase cache size to 500MB".
To run the script, download it from the Gist here: open in LINQPad then hit F5. It prompts for a folder - this should be the folder containing multiple cache status files which you downloaded (multiple files named something like CacheStatus.20260720Z.213238Z.html).
The script creates a subfolder under the directory you selected named "output" which will now contain a file named "cache_status_report.csv" which looks like this:
Spreadsheet Screenshot of Sitecore Aggregated Cache Statistics. - Shows min/max/avg for Count and Size - Shows values in the same units as the configured size (the size units used in the Sitecore config patch) - Indicates if a cache requires resizing with a suggested new value
To examine individual caches and explore how their usage varies over time, there is a chart function on the script. Go to "Select a Cache" on the output pane, select the cache name (only ones which need adjustment are listed) then on the Results pane you will see a line chart of the size over time. The chart includes the maximum cache size (as defined in the Sitecore configs) and also the recommended new cache size.
Under the "Select a Cache" tab is a dropdown list where you can chose which cache to show a chart for.
Chart output showing cache size variation over time. The purple line shows the current Sitecore cache size as defined in config patch file. The green line shows the recommended new value to set for the cache size (this would require an update/patch to the relevant patch config file). In this example, you can see that we are hitting the limit on a regular basis so we definitely need to increase the size of that cache in our config files.
Wrap Up
Thanks for reading if you go this far. If you have any comments, questions, suggestions or ideas, please drop a comment below.
Thanks!