How the Sitecore ASP.NET CMS Caches Output

This blog post describes how the Sitecore ASP.NET CMS caches the output of individual presentation components. For more information about presentation components, see the Presentation Component Reference Manual on the Sitecore Developer Network (SDN). For more information about caching with Sitecore, see the Cache Configuration Reference on SDN.

The Presentation Component materials on SDN (including the Reference and the Cookbook) describe how you can use Sitecore output caching, but don't describe its internal implementation.

Before undersanding how caching works, remember that Sitecore does not generate pages. Sitecore enhances the process for assembling the control tree that ASP.NET uses to generate pages by binding presentation components to placeholders in layouts and sublayouts.

Sitecore does not cache entire pages, but caches the output of individual components. Each component can generate multiple cache entries under different conditions, such the data source of the rendering, query string parameters and other criteria.

Sitecore uses the following basic approach to insert caching logic into the page generation process:

  • All presentation components inherit from the Sitecore.Web.UI.WebControl abstract base class and implement the DoRender() method. Sitecore uses Sitecore.Web.UI.WebControls.Sublayout for sublayouts and Sitecore.Web.UI.WebControls.XslFile for XSL renderings, each of which inherits from Sitecore.Web.UI.WebControl.
  • Along with other events in the page lifecycle, for each presentation component, when ASP.NET generates a page, ASP.NET calls the Render() method of Sitecore.Web.UI.WebControl.
  • If an entry exists in the cache, the Render() method writes the cached data to the output stream; otherwise it calls the DoRender() method. If caching options for the presentation control dictate and no error occurred, the Render() method of the Sitecore.Web.UI.WebControl class adds the output of the control to the output cache.

This might be redundant (especially with my blog post Custom Caching Criteria with the Sitecore ASP.NET CMS), but it seems appropriate to describe how Sitecore determines the key to the cache.

Each presentation component should implement the GetCachingID() method of the Sitecore.Web.UI.WebControl class to return something that identifies the control. The Sitecore.Web.UI.WebControls.Sublayout and Sitecore.Web.UI.WebControls.XslFile controls implement this method to return the path to the .aspx or .xslt file. Your web controls should implement a method such as the following (or implement this in an abstract base class that inherits from Sitecore.Web.UI.WebControl for all of your web controls inherit):

protected override string GetCachingID()
  return this.GetType().FullName;

The output cache acts something like a hashtable, but somewhat more complex as you can see from my blog post Schedule Expiration for Output Cache Entries with the Sitecore ASP.NET CMS. Whether adding or retrieving a cache entry, to determine the key to the cache for a control, Sitecore invokes the GetCacheKey() method of the Sitecore.Web.UI.WebControl class, which in turn invokes the GetCachingID() method. If you simply mark a control as cachable, Sitecore uses the result of calling the GetCachingID() method plus a string that identifies the context language as the key for the cache entry. If you select additional VaryBy parameters (as described in the Presentation Component Reference Manual), Sitecore adds additional strings to the key.