Planning for Cache in Sitecore

Wednesday, March 08, 2017 @ 08:15

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

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" 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.

Cache Managers Image

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 is to review each rendering that is created and set the appropriate HTML level caching on it.

HTML Cache List Image

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.

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.

VaryByData

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.

VaryByDevice

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.

VaryByLogin

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.

VaryByParm

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.

VaryByQueryString

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.

VaryByUser

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 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.

Other Caches

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

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.

 

 

Scott Gillis, Lead Consultant at Paragon and 2017 Sitecore MVP, has been working with Sitecore for several years. He has a deep passion for helping clients leverage their content and data into powerful new capabilities in Sitecore and has produced successful outcomes as the technical lead on numerous, complex implementations. Recently, Scott has been focusing on helping these clients take advantage of the wealth of data collected by Sitecore Experience Analytics.