There are few things more rewarding in site performance than enabling the Output Cache. This will store the ready-generated HTML to be served without executing any WebForms pages or Controller actions and their respective Views for MVC sites.
In Episerver, the output cache is enabled in the applicationSettings element’s httpCacheExpiration attribute in web.config. That sets the default Duration for a page.
Note that requests are not saved to the output cache if any of the following criteria are true:
- Current user is authenticated
- Duration (httpCacheExpiration in web.config) is zero.
- The HTTP method is not GET
In addition, requests are not served from the output cache if the DataFactoryCache.Version has changed since it was cached.
Please note that Output Caching makes Visitor Groups not work for anonymous visitors, which might be a deal-breaker for some.
When new content is published in Episerver, the item saved is clearly known so the cache for that item is dropped from the Object Instance cache. However, which of the output caches that needs to be re-rendered cannot be known. This is because any type of querying can be done to retrieve a content item or data from another content item. In the end, the generated HTML for a page is almost always a mix of many content items; menus and their labels are generated from the names of the pages they link to, content lists, children listings and many other elements provides summary information from other pages.
Thus, when any content item is saved, the DataFactoryCache.Version is updated and this causes all output caches to be invalidated.
As long as the page is stored in the output cache, the servers easily handles incoming load. When the page expires, the server goes through the process of rendering it from start to finish. Under very high load, the number of requests that ‘falls through’ the cache and simultaneously starts a process to render the same page may grow large enough to cause excessive delays in rendering and high loads on the supporting infrastructure such as databases and services. This is called a cache stampede.
Enter the Burst Cache
The idea of the burst cache is to limit the impact of dropping the output caches when they time out (Duration) or them all being invalidated at the same time when new content is published. This works by storing the version of the item in the cache and, in the case when a request was let through to re-render it, the version being rendered.
Only one thread is let through to re-render each output cache, while the other requests hitting one of those will continue to serve the (now slightly stale) cache.
Clone it from GitHub: EPiServer.BurstCache
2 responses to “A Burst Cache implementation released”
Oh…caching…we do like caching 🙂