By: Scott Gillis, Lead Consultant – This is a follow-up to my Unofficial Sitecore Planning Checklist, where I try to consolidate as much information as I could 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 serve-up 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 the site's cache is configured and tuned, be aware that the need for vertical or horizontal scaling may become necessary. For details on scaling Sitecore, checkout Scalability
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" value="true"/> </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 a 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.
The first level of caching to configure is to review each rendering that is created and set the appropriate HTML level caching on it.
To turn the HTML cache on for a rendering, select the first option Cacheable. From here you can customize how the different variations of the control should be cached via the different 'Vary By' options. Finally, you can mark that all caches be cleared when the search index is updated via the 'Clear on Index Update' selection.
The following full description of each cache option is taken from Chapter 4: Output Caching in Sitecore CMS 7.0 or later Presentation Component Reference.pdf.
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:
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:
The VaryByDevice property controls whether or not caching varies based on the name of the context device.
Set the VaryByDevice property:
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:
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:
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:
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 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 on whether or not a user has been 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.
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.