Sitecore 7: Output Caching by Index

This blog post describes the Clear on Index Update caching option introduced in version 7 of the Sitecore ASP.NET web Content Management System (CMS). Before you read this blog post, please read the Sitecore 7: Introduction blog post linked in the list of resources at the end of this page.

Search indexes are increasingly important to Sitecore renderings, which means the output of a greater number of renderings depends on the data in a search index. You can use the feature described in this blog post to remove entries from the output caches associated with your managed sites automatically after updating a search index.

Sitecore adds the Clear On Index Update output caching option:

screen capture showing clear on index update caching option

Like the Vary by parameters, if you select the Clear on Index Update caching option, Sitecore adds a token(_#index) to the caching key for the control. Unlike the Vary by options, Sitecore does not specify a value for that key.

The /App_Config/Include/Sitecore.ContentSearch.config Web.config include file specifies a handler for the new indexing:end and indexing:end:remote events to remove such cache entries after indexing operations complete. Specifically, the Clear() method of the Sitecore.ContentSearch.Maintenance.IndexDependentHtmlCacheManager class in the new Sitecore.ContentSearch assembly iterates the managed sites and removes all entries with keys that contain the _#index token from the output cache.


  • Hi Jens,  As long as your custom index is defined within the <contentSearch /> section, the IndexDependentHtmlCacheManager will be triggered.  Cheers, <alex />

  • Hi John,  We'd like to leverage Solr's index replication to setup an environment with a dedicated master index server and multiple slave servers which only process queries and pull copies of the master index as described in the Solr documentation.  With regards to Sitecore caching, do you have any recommendations as to how we can ensure that the output caches are cleared on the slaves after index updates have been replicated?  We've been playing around with a Solr postCommit hook to see if that can raise the Sitecore event which clears the index-dependent caches, but we're still sometimes having to manually clear the HTML caches after a publish so doesn't look like that's a reliable method.  Thanks, Valerie

  • I have some ideas, but would probably have do really dig in to determine what would work, and don't any experience with SOLR.  Maybe you could use a custom indexing strategy:  Maybe you could use that postCommit hook to raise the Sitecore event that leads to the cache clearing. Or you could do something custom on postCommit based on that existing cache clearing logic. If SOLR does not raise that postCommit event reliably/at the right time, I am not sure how you could make it reliable, other than some kind of polling mechanism to check for last completion time.

  • Is there a similar solution for sitecore 6.6

  • I don't know of anything like this for Sitecore 6, but as long as you can get something into the cache keys for the renderings that depend on the index, you could do something similar with that version. Maybe you could use VaryByParam with a parameter named index that provides the name of the index.

  • I set "cacheHtml=true" in web.config file and set "cacheable" for added sublayouts. When I reflash the page, cache is enabled. However, all templeates' field values are empty in the sublayout's placeholder on the page.  The sublayout uses extra parameter templates for dynamic values.  Checked - Cacheable Checked - Vary by Data Checked - Vary by Parameters Checked - Vary by Query String  What is the issue?  All template values are not from __Standard Values, it is dynamic.

  • @Jihyun: Have you published the definition item for the rendering with the Clear on Index Update checkbox selected? To confirm, you browse the page on the published site (not the Page Editor/Experience Editor/etc.) to populate the cache?