HST Enterprise Caching Overview

Info: HST Enterprise Caching is available only with a standard or premium Bloomreach Content license. Contact Bloomreach for licensing details.

The Second Level Page Cache and Cluster-Wide Caching features (both using Redis) were deprecated in version 14 and removed in version 15.0. The Stale Page Caching feature was also removed but reintroduced in versions 15.7 and 16.1.

Introduction

Purpose

This page explains how enterprise caching features in Bloomreach Content's delivery tier operate and how they extend the default caching capabilities.

Context

Enterprise Caching enhances Bloomreach Content's page caching by enabling more efficient cache reuse across delivery tier cluster nodes. It also supports domain-specific optimizations through cluster-wide caching.

This documentation describes the available Enterprise Caching features, their mechanisms, and their benefits compared to standard caching.

For configuration and monitoring instructions, see Enable and Configure HST Enterprise Caching and Monitor HST Enterprise Caching.

HST Enterprise Caching Features

Enterprise Caching provides the following features:

Stale Page Caching (available in versions 14.x, 15.7, 16.1 and later)
Second Level Page Caching (available in 14.x, deprecated)
Generic Cluster-Wide Caching (available in 14.x, deprecated)

Stale Page Caching enables the delivery tier to serve a stale page to multiple visitors while a single request triggers page regeneration. Once the page is refreshed, new visitors receive the updated content.

Second Level Page Caching (deprecated) allowed a cached page to be shared across all cluster nodes and extended the cache duration beyond the default page cache. Only one node in the cluster generated the page, and all nodes served the same cached result.

Both Second Level Page Caching and Stale Page Caching are compatible with Hippo Relevance for personalized content.

Generic Cluster-Wide Caching (deprecated) supports domain-specific optimizations. For example, you can prevent every cluster node from making the same expensive remote REST call by caching the result in a shared cache. You can also use it to store visitor information (such as click paths) in a stateless way, without relying on sticky sessions or HTTP sessions.

These caches operate independently. Enable only the caches required for your implementation.

Page Cache Improvements with Enterprise Caching

Bloomreach Content includes a default page cache (First Level Page Caching), which significantly improves performance for high-traffic pages. For example, it can serve 10,000 homepages per second compared to 500 per second without caching. However, the default cache is volatile: any content change in the repository clears the entire cache, since the delivery tier cannot determine which pages are affected.

If you configure the default cache to serve stale pages for a fixed period (e.g., 5 minutes), you risk inconsistent user experiences. Different cluster nodes may serve different versions of a page, leading to inconsistent results for the same visitor. If you accept cluster node affinity for visitors, you can use the First Level Page Cache with the following settings:

pageCache.timeToLiveSeconds = 300
pageCache.clearOnContentChange = true

For details, see HST Page Caching.

Stale Page Caching reduces latency for high-traffic pages during concurrent content changes and improves protection against the thundering herd problem. The First Level Cache includes thundering herd protection: when 100 visitors request the same page, only one request generates the page, and all others receive the result once it's ready. However, if page generation is slow (e.g., due to a remote REST call), all waiting visitors occupy server threads, which can exhaust container resources (maxConnections, acceptCount, maxThreads in Tomcat).

Stale Page Caching addresses this issue. When 100 visitors request the same page, only one request triggers page regeneration. Before regenerating, the system restores the stale page from the Stale Page Cache into the First Level Cache (if available). The waiting visitors are immediately served the stale page, freeing up server threads. The regenerating request proceeds to build a fresh page, which is then stored in both caches.

Deprecated Caches

Second Level Page Cache and Generic Cluster-Wide Cache are available in version 14 but are deprecated and removed in version 15 and later due to reliance on an outdated Redis integration.

With Second Level Page Caching enabled, slow pages are cached more effectively. All cluster nodes serve the same cached page, and cache entries can have longer lifetimes (e.g., 180 seconds). Content changes may take up to the cache duration to appear on the live site. Adjust the cache duration as needed for your use case.

Typically, responses are served from the First Level Cache. On a cache miss, the system checks the Second Level Cache. If found, the response is restored to the First Level Cache with an adjusted time-to-live.

Combining Second Level Page Caching and Stale Page Caching with the First Level Caching increases cache effectiveness and consistency. This combination is supported only in brXM version 14.