This is a follow-up to my Unofficial Sitecore Planning Checklist, where I try to consolidate as much information as I can find on Sitecore’s built in caching.
One of the easiest ways to improve a visitor’s perceived impression of any website visit is through a well-tuned cache. A cache which has been properly tuned will be able to server of requested content quicker, sometimes magnitudes faster than rebuilding the HTML for a page on each request.
Sophisticated caching scenarios can be configured through third-party tools and applications, but even for the most highly trafficked site properly tuning Sitecore’s different cache options should provide the desired performance gains. As site cache is configured and tuned, be aware the need for vertical or horizontal scaling may become necessary. (For details on scaling Sitecore checkout Scalability)
Determine the cache limits required
The general practice for Sitecore caching tuning is to turn all cache limits off via the following simple cache patch config:
<configuration xmlns:patch="http://www.sitecore.net/xmlconfig/"> <sitecore> <settings> <setting name="Caching.DisableCacheSizeLimits"> <patch:attribute name="value">true</patch:attribute> </settings> </sitecore> </configuration>
With the cache limits now disabled, Sitecore will try to manage based on current traffic and available resources to cache as much as possible. By performing well structured load test or allowing the site to run in this manner, the team should monitor both server resource utilization as well as the Sitecore cache levels to determine areas that should be manually limited to maximize performance.
To monitor what Sitecore has cached you can use the Sitecore admin page, http://< your domain >/Sitecore/admin/cache.aspx, or leverage the Sitecore Marketplace module Caching Manager, https://marketplace.sitecore.net/en/Modules/Caching_Manager.aspx.
After data collection has occurred you are ready to begin to evaluate which caches need their limits adjusted from the default level. For more information on the different cache limits that can be set see Sitecore CMS 7.0 – 7.2 CMS Performance Tuning Guide.pdf and Sitecore CMS 6.6 or later Cache Configuration Reference.pdf.
Configuring HTML Cache of Components
The first level of caching to configure to is review each rendering that is created and set the appropriate HTML level caching on it.
To turn HTML cache on for the rendering, select the first option Cacheable. From here you can customize the how different variations of the control should be cached via the different ‘Vary By’ options. Finally, you can mark that all cache be cleared when the search index is updated via the ‘Clear on Index Update’ selection.
The following fuller description of each cache option is taken from Chapter 4: Output Caching in Sitecore CMS 7.0 or later Presentation Component Reference.pdf.
Clear on Index Update
The Clear on Index Update property controls whether or not a control clears its cache when an item that is associated with the control is updated in the index. This is useful for any control that uses the new Search API to populate its data sources. For example:
- You have a control that returns all the products that are on special offer from the index.
- The Clear on Index Update property for this control is set to True.
- The price of each product is stored in the index.
If someone updates the price of one of the products on special offer, the Clear on Index Update property will the trigger the control to clear its cache because something has been updated in the index that is bound to the control.
The VaryByData property controls whether or not output caching varies based on the data source of the presentation component.
Set the VaryByData property:
- To False for components that do not generate different output when used with different data sources.
- To True for components that generate different output when used with different data sources.
The VaryByDevice property controls whether or not caching varies based on the name of the context device.
Set the VaryByDevice property:
- To False for components that do not generate different output when used with different devices.
- To True for components that generate different output when used with different devices.
The VaryByLogin property controls whether or not output caching varies based on whether or not the user has authenticated. For caching configuration involving the VaryByLogin property, the layout engine treats all anonymous users as a single authenticated user.
Set the VaryByLogin property:
- To False for components that do not generate different output for authenticated than for unauthenticated visitors.
- To True for components that generate different output for authenticated than for unauthenticated visitors.
The VaryByParm property controls whether or not output caching varies based on rendering parameters passed to the presentation component. Solutions built with earlier versions of Sitecore may have used the token VaryByParam instead of VaryByParm. Update any instances of VaryByParam to VaryByParm.
Developers set the VaryByParm property:
- To False for components that do not generate different output when passed different rendering parameters.
- To True for components that generate different output when passed different parameters.
The VaryByQueryString property controls whether or not output caching varies based on query string parameters passed in the URL. The VaryByParm property causes output caching to vary based on rendering parameter values passed by the developer. The VaryByQueryString property causes output caching to vary based on parameters passed in the URL query string.
Developers set the VaryByQueryString property:
- To True for components that generate different output when supplied different query string parameters.
- To False for components that do not generate different output when supplied different query string parameters.
The VaryByUser property controls whether or not output caching varies by the domain and username of the context user.
Developers set the VaryByUser property:
- To False for components that do not generate different output for different users.
- To True for components that generate different output for different users, when the number of active users between publishing operations is relatively small. The VaryByUser treats all anonymous users as a single authenticated user.
To avoid excess memory consumption, avoid using the VaryByUser property except in solutions with relatively small numbers of users, or monitor cache utilization closely. The VaryByLogin property causes Sitecore to generate different output depending based on whether or not a user has authenticated, differentiating anonymous users from authenticated users. The VaryByUser property causes Sitecore to generate different output for each user
Sitecore contains a number of other caches that help to lower the number of calls required to the database for item information and indexes. These are best described in a post from the Sitecore Tactics blog entitled How Sitecore caching work.
Additional Helpful references
- Sitecore caching an overview
- Sitecore hidden ‘cache’ configuration settings
- Caching Manager in Sitecore 8
- 27 Tips: Configuring Sitecore for Performance, scalability, and security
- How Sitecore caching work
One Final Note
Starting in Sitecore 8.2, the Cache APIs where refactored, creating breaking changes to any custom cache providers used in previous versions. Be sure to check out the change list, https://doc.sitecore.net/sitecore_experience_platform/developing/developing_with_sitecore/cache_api_changes.