HST Page Caching (Context-Aware Cache)

Bloomreach Experience Manager's delivery tier (HST) includes apage cache valve. Its primary focus is:

1. Make surehotspot pages can be served at very high volumes and frequently from cache.
2. Make surethundering herds are less harmful because the page cache is blocking : Only a single request for a single page cachekey will be processed concurrently. All concurrent requests for the exact same page will be blocked and served a rendered response by a single request.

In the section above we explicitly mentionhotspot pages. The reason for this is that the HST page cache is not suited for 'fixing' really bad  performing pages (for example pages that have to wait on very slow server side remote service rest calls). The primary goal of the HST page cache is to optimize already well performing pages in such a way that they become blistering fast. 

The page caching works well for personalized sites as well, for example with theRelevance Module.

Enterprise Caching 

An Enterprise Caching module is available which supports, in addition to the open source (first level) page caching, also stale page caching, making the page cache more powerful. 

Serving 20.000+ pages per second

The HST page cache serves more than 20.000 pages per second once a page is cached. This is an enormous throughput, certainly if you realize that for a request that has a cached response, the HST still does:

1. Host, mount and sitemap item matching.
2. Look up the component configuration and checks whether the component tree iscacheable.
3. Executes all the initialization valves, all the processing valves until the pageCachingValve, and all the clean up valves.

Because the HST design scales very well up and out, page caching can serve such a large throughput while still doing all the processing mentioned above.

Seamless integrated with personalized pages

When usingRelevance to support personalized pages, the page cache works as well because the computed profile for the visitor is included in the cache key.

Usage

By default, page caching is not enabled. Enabling page caching can be done runtime in the repository. Caching is always disabled for the following requests:

1. ActionURLs
2. Preview sites 
3. Sites in Experience manager
4. Requests that are processed withsubjectbasedsession. 

The caching valve is currently included in the following pipelines

1. DefaultSitePipeline (normal html page rendering)

2. JaxrsRestContentPipeline (see RESTful JAXRS component support)

3. JaxrsRestPlainPipeline (see RESTful JAXRS component support)

4. restApiPipeline (see Content REST API)

5. PageModelPipeline (seeDelivery API)

Caching for normallive sites can be switched on and off on different levels of HST configuration. It can be switched on/off per: 

1. Hosts,Host,Mount orSitemapItem configuration. 
2. HST component configuration

 A renderedresponse is onlycacheableif and only if the matched sitemap item iscacheable and the root component that the matched sitemap item points to iscacheable.

Cacheable configuration onHosts,Host,Mount andSitemapItem level

To switch on caching globally for all pages for all channels, you can set onhst:hosts the propertyhst:cacheable=true. Everyhst:host, subhost,mount, submount andsitemap items now inherits this property. When not configured onhst:hosts, caching is false. Everyhost, subhost,mount, submount orsitemap item can override this cacheable property. Everything below the item that did override the value, inherits the overridden value.

For example, assume your configuration looks like:

/hst:hosts:  hst:cacheable: false  /dev:    /localhost:      hst:cacheable: true      /hst:root:        /nl:          hst:cacheable: false    /127.0.0.2:      /hst:root:        /nl:          hst:cacheable: true

In this example, both localhost/hst:root and127.0.0.2/hst:root/nl havecaching set to true. 

In a sitemap, all items are by default cacheable or not depending on thehst:mount. If themount is cacheable, then thesitemap is cacheable by default.

For example, assume the mount hashst:cacheable = true, and thesitemap looks as follows:

/hst:sitemap:  /home:  /news:    /*:      hst:cacheable: false      /*:        /**.html:          hst:cacheable: true

Then the itemshome,news andnews/*/*/**.html are cacheable, and the itemsnews/* andnews/*/* areuncacheable.

Cacheable configuration on HST component configuration 

By default, everyhst:component is cacheable. When anhst:component needs to beuncacheable, you can indicate this throughhst:cacheable=false.

Acomposite tree of HST components is only cacheable if every HST component in the composite structure of components that will be rendered during the request is cacheable

Note that the above thus excludes HST components that are marked ashst:async=true, as those components arenot rendered during therequest. Also seeasync rendering. Usingasync can thus be very useful for renderinguncacheable components. However realize thatasync components cannot contribute to hstheadContributions (for example the title of the page or some javascript to be added in the head or at the bottom of the html)

Marking pages during rendering as uncacheable

There are two situations through which a page that is marked as cacheable by the sitemap item and/or hst component but that the page in the end still won't be cached:

1. Setting one or morenon-caching header : If a developer puts during rendering (HstComponent /jsp /ftl) to the response a Pragma no-cache, or a Cache-Control no-cache or an expires of 0 or lower, the rendered response won't be cached
2. Setting cookies on the response : If a developer sets during rendering (HstComponent /jsp /ftl) sets cookies on the response, the rendered response won't be cached. Note that cookies set by the HST framework won't influence caching. Also note thatHttpSession cookies do not influence caching. If you create a HttpSession as developer and the page cannot be cached, you should either set a non-caching header or mark the hst component as uncacheable.

Page Cache Configuration options

The following hst config properties (seeHST container configuration) can be set and have the following values by default:

pageCache.maxSize = 1000pageCache.timeToLiveSeconds = 3600pageCache.clearOnContentChange = true (since CMS 11.2.0)pageCache.clearOnHstConfigChange = true (since CMS 11.2.0)

ThemaxSize refers to how many page responses will be kept in memory as a maximum (LRU eviction policy after max size has been reached) and is by default 1000. If you make this value larger, make sure that your application has enough memory. The timeToLiveSeconds is themaximum time a cached response is valid. After this time, a page is always recreated. 
The clearOnContentChange means that on any content change, the entire cache is flushed. The reason for this is that the HST cannot know on which pages the changed/updated/new/deleted content should be shown, hence, the entire cache is flushed by default on any content change. We could had chosen to not clear the entire cache, but instead, for example use atimeToLiveSeconds of 300 (5 minutes), and accept that at most after 5 minutes a content change becomes visible for a live site. There is however one downside with this strategy: In a clustered setup you could end up with two cluster nodes serving a different page for the same URL for some time. This is in general unacceptable, unless your loadbalancer uses node affinity any way, making sure that the same visitor gets directed to the same cluster node all the time. In this scenario, it might be acceptable that changes become visible after, say, 5 minutes. In that case, configure:

pageCache.timeToLiveSeconds = 300pageCache.clearOnContentChange = false

The clearOnHstConfigChange is the same as clearOnContentChange only now for changes in HST configuration.