HST Page Caching (Context Aware Cache)
The HST includes a page cache valve. Its primary focus is:
- Make sure hot spot pages can frequently be served from cache.
- Make sure stampeding 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.
The cache works well for personalized sites as well, for example through targeting.
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:
- Host, mount and sitemap item matching.
- Look up the component configuration and checks whether the component tree is cacheable.
- 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 using Hippo Relevance to support personalized pages, the page cache works as well because the computed profile for the visitor in included in the cache key.
By default, page caching is disabled. Caching is always disabled for
- action URLs
- preview sites
- sites in cms channel manager / template composer
- requests that are processed with subjectbasedsession.
The caching valve is currently only included in the DefaultSitePipeline, so currently not for jaxrs pipelines. Caching for normal live sites can be switched on and off on different levels of HST configuration. It can be switched on/off per:
- Hosts, Host, Mount or SitemapItem configuration.
- HST component configuration
A rendered response is only cacheable if and only if the matched sitemap item is cacheable and the root component that the matched sitemap item points to is cacheable.
Cacheable configuration on Hosts, Host, Mount and SitemapItem level
To turn on caching globally for everything, you can set on hst:hosts the property hst:cacheable=true. Every hst:host, sub host, mount, sub mount and sitemap items now inherits this property. When not configured on hst:hosts, caching is false. Every host, sub host, mount, sub mount or sitemap 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 and 127.0.0.2/hst:root/nl have caching set to true.
In a sitemap, all items are by default cacheable or not depending on the hst:mount. If the mount is cacheable, then the sitemap is cacheable by default.
For example, assume the mount has hst:cacheable = true, and the sitemap looks as follows:
+hst:sitemap + home + news + * - hst:cacheable = false + * + **.html -hst:cacheable = true
Then the items home, news and news/*/*/**.html are cacheable, and the items news/* and news/*/* are uncacheable.
Cacheable configuration on HST component configuration
By default, every hst:component is cacheable. When an hst:component needs to be uncacheable, you can indicate this through hst:cacheable=false.
A composite 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
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:
- Setting one or more non-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
- 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 that HttpSession 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.