Tips for Monitoring and Tuning Sitecore Cache

Utilizing caching improves Sitecore performance and there are plenty of posts on this topic. While doing some performance analysis on an inherited solution I was surprised to find that caching was not being utilized to its full potential. In this post, i’ll share some useful scripts and tools that make the task of monitoring and tuning cache settings easier.

Sitecore Cache

Sitecore provides various caches and levels of caching to improve the performance. The cache configuration reference guide provides detailed information on the various caches and settings. Yogesh Patel is his post How Sitecore cache works provides a great overview of these various caches.

Configuring HTML Cache

The HTML cache is an output cache that caches renderings. Caching components is not the answer to poor performing code. Potential bottlenecks in code should be identified and addressed first. Then look at how the various caching options can be utilized to make your site even more perform-ant. It is important to understand how the various options work, what gets cached and how these values are accessed. As this will help ensure your components are cached efficiently:

  • Cacheable – For the rendering / sub layout to be cached – it first needs to be checked as Cacheable.
  • Clear on Index Update – When you select Clear on Index Update, Sitecore clears the HTML cache of renderings when the index is updated.
  • Vary By Data – The cache key is: controller::[Controller]#[Controller Action]#lang:[Language Culture Code]#data:[Path of the Datasource Item] Since, the path to each data source item is different, the output cache varies by change in Datasource. NOTE: If the Vary by Data is enabled but the data source has not been set then the context item will be used for the key. This would mean a different cached item for every page visited. It is important that you verify components that don’t have a data source and instead don’t check this option. As it is an inefficient use of caching. Cacheable by itself will ensure the component is cached without an additional key required.
  • Vary by Device – The cache key is: controller::[Controller]#[Controller Action]#lang:[Language Culture Code]#dev:Responsive Allowing you to output different cache keys for different Sitecore Devices.
  • Vary by Login – Key controller::[Controller]#[Controller Action]#lang:[Language Culture Code]#ogin:FalseWe can output different cache keys based on if user is logged in or not.
  • Vary by Parameter – cache key is: controller::[Controller]#[Controller Action]#lang:[Language Culture Code]#parm:[Key=Value] Allowing different cache for the same rendering based on the different rendering parameters.
  • Vary by Querystring – cache key is: controller::[Controller]#[Controller Action]#lang:[Language Culture Code]#qs:[request.QueryString] By adding the current request query string to the key we can different cached rendering based on the query string values.
  • Vary by User – The cache key is: controller::[Controller]#[Controller Action]#lang:[Language Culture Code]#user:extranet\Anonymous This appends the current Context user to the key. If the user is not logged in, this will be extranet/anonymous when using a default site definition.

While Sitecore OOTB provides a varied range of rendering cache settings they don’t always cover every scenario. One common scenario is the handling caching of content on wildcard page templates. Thankfully these can be easily extended one common addition to these settings is implementing a custom Vary by Url or Vary by Id cache key.

Component level Caching Vs Page level Caching

You can specify rendering caching options in two ways:

  • Globally – specifying the options in the definition item of the rendering. This is then the default setting for all uses of this rendering.
  • Locally – specifying the options every time you use a rendering.

Note: If you change the cache settings for a component at the page level it will override the default global settings.

How to check Rendering Cache Settings

I wanted to easily list all renderings and their cache settings i.e. global cache settings. Sitecore SPE to the rescue:

$controllerRenderingTemplateId ="{2A3E91A0-7987-44B5-AB34-35C2D9DE83B9}"
Get-ChildItem -Path "master:\layout\Renderings" -Recurse |
Where-Object { $_.Cacheable -match "1|"} |
Select-Object -Property Name, ID, Path, Cacheable, ClearOnIndexUpdate, VaryBy* |
Sort-Object -Property Name | Show-ListView

I also wanted a list of all the renderings used on a specific content item and their cache settings as this allows me to verify settings on a specific page i.e. local cache settings.

$database = "master"
$selectedItem = Get-Item -Path (@{$true="$($database):\content\home"; $false="$($database):\content"}[(Test-Path -Path "$($database):\content\home")])
$props = @{
Parameters = @(
@{Name="selectedItem"; Title="Choose the Sitecore Item to to view its Renderings Settings"; Tooltip="All Final Renderings and their settings for this item wil be listed "; }
Title = "List Rendering Cache Settings for Content Item"
Description = "Please select Content Item"
Width = 550
Height = 300
ShowHints = $true
Icon = [regex]::Replace($PSScript.Appearance.Icon, "Office", "OfficeWhite", [System.Text.RegularExpressions.RegexOptions]::IgnoreCase)
$result = Read-Variable @props
if($result -eq "cancel") {
if ($selectedItem.length -ge 1) {
$selectedItemID = $selectedItem.ID
$defaultLayout = Get-LayoutDevice -Default
$selectedItem = Get-Item -Path "master:" -ID $selectedItemID
$Results = @();
$renderings = Get-Rendering -Item $selectedItem -Device $defaultLayout -FinalLayout
foreach($rendering in $renderings){
if($rendering.ItemID -ne $null)
$renderingItem = Get-Item master: -ID $rendering.ItemID
if($renderingItem -ne $null)
$Properties = @{
Page = $rootItem.Name
RenderingItemName = $renderingItem.Name
RenderingItemID = $renderingItem.ID
RenderingItemPath = $renderingItem.Paths.Path
Global_Cacheable = $renderingItem.Cacheable
Global_ClearOnIndexUpdate = $renderingItem.ClearOnIndexUpdate
Global_VaryByData = $renderingItem.VaryByData
Global_VaryByDevice = $renderingItem.VaryByDevice
Global_VaryByLogin = $renderingItem.VaryByLogin
Global_VaryByParm = $renderingItem.VaryByParm
Global_VaryByQueryString = $renderingItem.VaryByQueryString
Global_VaryByUser = $renderingItem.VaryByUser
$Results += New-Object psobject -Property $Properties
$Results | Select-Object Page, RenderingItemName,RenderingItemID,RenderingItemPath,Global_Cacheable, Global_ClearOnIndexUpdate, Global_VaryBy* | Show-ListView

Michael West provides some useful examples working with renderings and cache settings i.e. enabling and disabling settings etc.

Simple Cache Performance Test

You can perform a relatively simple test to check if your solution will benefit from adjusting rendering cache settings. Note this is a simple test and we are not concerned with how efficiently we are caching components and utilizing the cache keys at this stage.

  1. Run your baseline load Test on your test/stage environment. If you are not familiar with Load testing may I suggest starting here.
  2. Backup your Sitecore rendering components by creating a Sitecore package. So we can easily revert back after testing.
  3. Run the powershell extension to enable caching on all components.
  4. Re-run your baseline load test.
  5. Compare results. If you see significant improvement in load test results average, min and throughout you should invest time reviewing cache settings for the various components.
  6. Remember to restore your rendering components from the Sitecore package.

Cache Tools

Monitoring and Tuning the Cache Settings is an interative approach as the solution evolves the Caches settings require continual monitoring and configuring for optimal performance. Sitecore provides some tools out of the box:

  • Cache Admin – provides information about each of the Sitecore caches. It is used to monitor Sitecore cache utilization and to clear the Sitecore caches if required. It allows you to see all the caches, how much memory can be allocated to it, and how much of it is in use.
  • Rendering Statistics – provides information about each of the renderings for which an entry exists in each site HTML (output) cache. It can be used to identify under-performing renderings and renderings for which you can improve cache configuration.
  • Profiling Tool – accessible via the Sitecore Experience editor the debug profiling tool provides detailed performance analysis of the components that comprise of a page. This includes information in Data Cache Hits, Data Cache Misses.

These tools are accessible via Sitecore Content Management. But we need to be able to monitor the cache on our Content Delivery Roles. For various security reasons the CM is not accessible on a CD.

  • Cache Tuner V2 – is popular community tool which allows you to not only monitor cache utilization but also peak inside the HTML cache to see what is actually being cached. This is extremely useful as it can help you understand how your components are being cached and if they are configured to utilize the cache efficiently. This is not something you want to make publicly available so if you do add it to a production environment make sure you take necessary steps to lock it down.

Steps to tune cache settings

  1. Check the Cache size settings and ensure you are not using the default values.
  2. Review all rendering cache settings (SPE scripts simplify this process). Both global and local settings.
  3. Adjust rendering cache settings as required.
  4. Peek inside the HTML cache for your site(s) and ensure components are caching as you expect.
  5. Check for duplicate cached content, if they exist review the generated cache key and settings for these components.
  6. Hit every single page for your site(s) this can be achieved with this handy JMeter script to crawl your site using your sitemap while you monitor the cache sizes and environment resources.
  7. Tune the cache sizes accordingly and repeat steps 3-7.
  8. Run your baseline load test and compare results with any previous tests.

You should continually monitor cache sizes and entries and the Sitecore logs as your solution evolves. Making adjustments as required.

Cache Eviction & Cache Logs

There are several events that can cause data to be evicted from a cache like publishing or data change and these are covered in detail in the Sitecore Cache Configuration reference guide. However, when a cache reaches its size limit, Sitecore will evict one or more entries from the cache at random before adding a new entry.

If you see regular occurrences of the following warning it is an indication the configured size of the named cache needs to be tuned.

Warn [nameofcache] cache is cleared by Sitecore.Caching.Generics.Cache`1+DefaultScavengeStrategy  

The DefaultScavengeStrategy is responsible for determining what and how items are evicted from the cache. Zachary Kniebel provides more details in his answer on and helps clarify its inner workings.

João Neto does a great job covering the topic of cache logs in his series Understanding Sitecore logs: Part 2 Caches and XML Configuration load. I would suggest reading over it.

Useful Info

Happy Caching!

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s