HST Page Caching (Context-Aware Cache)

Bloomreach Content's delivery tier (HST) includes a page cache valve. The primary objectives of this cache are:

  1. Enable high-volume, frequent serving of hotspot pages directly from cache.
  2. Mitigate the thundering herd problem by blocking concurrent requests for the same page cache key. Only one request for a given page is processed at a time; all others wait and receive the cached response.

The cache is designed for hotspot pages—pages that already perform well. It is not intended to compensate for slow pages, such as those waiting on slow remote service calls. The goal is to further optimize fast pages for even higher throughput.

The HST page cache also works with personalized sites, including those using the Relevance Module.

Enterprise Caching

The Enterprise Caching module extends the open source (first-level) page caching by adding stale page caching. This provides additional caching capabilities.

Throughput: 20,000+ Pages per Second

Once a page is cached, the HST page cache can serve over 20,000 pages per second. Even when serving cached responses, HST performs the following steps for each request:

  1. Host, mount, and sitemap item matching.
  2. Component configuration lookup and cacheability checks.
  3. Execution of all initialization valves, all processing valves up to the pageCachingValve, and all cleanup valves.

HST's architecture supports horizontal and vertical scaling, allowing high throughput while maintaining these processing steps.

Integration with Personalized Pages

When using Relevance for personalized pages, the page cache remains effective. The visitor's computed profile is included in the cache key, ensuring correct cache segmentation.

Usage

Page caching is disabled by default. You can enable it at runtime in the repository. The following requests are never cached:

  1. Action URLs
  2. Preview sites
  3. Sites in Experience manager
  4. Requests processed with subjectbasedsession

The caching valve is included in the following pipelines:

  1. DefaultSitePipeline (standard 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 (see Delivery API)

You can enable or disable caching for live sites at different levels of the HST configuration. Caching can be controlled per:

  1. Hosts, Host, Mount, or SitemapItem configuration
  2. HST component configuration

A response is cached only if both the matched sitemap item and the root component it points to are marked as cacheable.

Cacheable Configuration on Hosts, Host, Mount, and SitemapItem

To enable caching globally for all pages and channels, set hst:cacheable=true on hst:hosts. All hst:host, sub-host, mount, sub-mount, and sitemap items inherit this property. If not set on hst:hosts, caching defaults to false. Any item can override the cacheable property, and its descendants inherit the overridden value.

For example:

/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 configuration, both localhost/hst:root and 127.0.0.2/hst:root/nl have caching enabled.

In a sitemap, items are cacheable by default if the hst:mount is cacheable. You can override this at the sitemap item level.

For example, if the mount has hst:cacheable = true and the sitemap is:

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

In this example, home, news, and news/*/**/*.html are cacheable. The items news/* and news/*/* are not cacheable.

Cacheable Configuration on HST Component Configuration

By default, every hst:component is cacheable. To make a component uncacheable, set hst:cacheable=false.

A composite tree of HST components is cacheable only if every component rendered during the request is cacheable.

Components marked as hst:async=true are excluded from this check, as they are not rendered during the main request. See async rendering for details. Using async components allows you to render uncacheable components separately. However, async components cannot contribute to HST headContributions (such as page titles or JavaScript in the head or footer).

Marking Pages as Uncacheable During Rendering

A page may be excluded from caching at render time, even if the sitemap item and component are cacheable, in the following cases:

  1. The response includes a non-caching header. If a developer sets headers such as Pragma: no-cache, Cache-Control: no-cache, or an Expires value of 0 or lower during rendering (in HstComponent, JSP, or Freemarker), the response will not be cached.
  2. The response includes cookies. If a developer sets cookies during rendering, the response will not be cached. Cookies set by the HST framework do not affect caching. HttpSession cookies also do not affect caching. If you create an HttpSession and want to prevent caching, set a non-caching header or mark the HST component as uncacheable.

Page Cache Configuration Options

You can configure the following HST properties (see HST container configuration). Default values are shown:

pageCache.maxSize = 1000
pageCache.timeToLiveSeconds = 3600
pageCache.clearOnContentChange = true (since CMS 11.2.0)
pageCache.clearOnHstConfigChange = true (since CMS 11.2.0)
  • maxSize: The maximum number of page responses kept in memory (using an LRU eviction policy). Default is 1000. Increase this value only if sufficient memory is available.
  • timeToLiveSeconds: The maximum time a cached response is valid. After this period, the page is re-rendered.
  • clearOnContentChange: When enabled, any content change flushes the entire cache. HST cannot determine which pages are affected by a content change, so the default is to clear all cached pages.
  • clearOnHstConfigChange: Functions like clearOnContentChange, but for HST configuration changes.

If you want to avoid clearing the entire cache on content changes, you can set a lower timeToLiveSeconds (for example, 300 seconds) and set clearOnContentChange=false:

pageCache.timeToLiveSeconds = 300
pageCache.clearOnContentChange = false

This approach means content changes may take up to 5 minutes to appear on the live site. In a clustered environment, this can result in different cluster nodes serving different versions of a page for a short time. This is generally not acceptable unless your load balancer uses node affinity, ensuring the same visitor is always directed to the same node. In such cases, delayed visibility of changes may be acceptable.

Share Feedback
Page: /about/for-architects/delivery-framework/hst-page-caching
Section: About
Category *