Docs Developer Site
DeveloperDocsBoosterStableHow It Works

How It Works

Contents

Dive deeper to understand how Booster works

Request conditions

A request is considered cacheable if the request:

  • Is an HTTP or HTTPS request.

  • Is a GET request. (Note, that HEAD requests can return cached response headers.)

  • Does not contain an Authorization header.

  • Does not correspond to a valid session.

  • Is a Site’s Portal request. (VHost target starts with or equal to /site)

  • Is a request to the master branch (draft items are never cached)

  • It’s URI does not contain /_/. (This is a convention for service requests.)

If the request is not cacheable, Booster will forward the request.

If the request is cacheable, Booster will check if a cached response is available, not stale and return it. Otherwise it will render, cache and return a new response.

Response Conditions

A response is considered cacheable if the response:

  • Returns 200 OK status.

  • Does not contain a Cache-Control header with private, no-cache or no-store directive(s).

  • Does not contain an Expires header. (Note: Any value of Expires header)

  • Does not contain a Set-Cookie header.

  • Does not contain a Content-Encoding header.

  • Does not contain a Vary header.

  • The Content-Type contains a supported value (default is text/html and text/xhtml)

  • Originates from the site engine (Internal XP path start with /site)

  • Booster is installed and enabled on the requested site

    • Application configuration allows request to be cached (Disabled is unchecked and request path matches configured cacheable Patterns)

If the response is cacheable, Booster stores the response in the cache.

Caching

The request URL is used as the cache key. To ensure optimal re-use of cached items, Booster will perform URL normalization by:

  • Sorting of query parameters

  • Lowercasing host and path

  • Removing excluded query parameters (based on config)

Booster then uses the underlying Node API to persist the cached items. As such, cached items will be available across all nodes in an XP cluster, optimizing performance and scalability even further.

Invalidation

Booster will automatically invalidate cache when one of the following events occur:

  1. Cache for the entire content project is automatically cleared when:

    • Content gets published/unpublished or expires

    • Project is deleted

    • Applications used by a site is installed

  2. Cache for a single item is automatically cleared when

    • Cache item reaches Time to live (TTL)

  3. All cache gets deleted when:

    • Applications listed in the configuration appsInvalidateCacheOnStart starts

When an item is invalidated, it is simply marked as invalid.

Cache can also be invalidated manually via the Content Studio Booster widget, or via the Booster API.

Invalid items are periodically removed from the cache by a background task. This task also enforces the cacheSize configuration setting.

Compressed Content

If the client supports Brotli or Gzip compression (determined from request Accept-Encoding header), Booster will serve a compressed version of the content.

Compression happens only once, occurs during cache creation

Brotli compression is preferred over Gzip. Gzip is preferred over uncompressed content.

Request Collapsing

"Thundering herd" is a scenario when multiple requests are made for a single resource at the same time. If the item is not cached, the traffic may potentially bring down your server.

To mitigate this situation, Booster implements a technique called request collapsing. This ensures only one of the requests are forwarded to the site engine for rendering.

Remaining requests are queued up for the response from the first request. Once the rendering is completed, the response is then sent to all the waiting requests.

Request collapsing only happens if the request is cacheable and a stale or invalidated cache item already exists.

For an XP cluster, request collapsing is performed on a per-node-basis, meaning the rendering process may occur once per node - until it is successfully cached.

304 Not Modified

Cached responses always contains an ETag header. If a request contains the If-None-Match header, Booster will try to match this with the stored ETag value.

If the values match, Booster will return a 304 Not Modified response and no data. This lets the browser use it’s local cache - saving network bandwidth and reducing latency.

Age, max-age and s-maxage

Booster supports max-age and s-maxage cache directives from the upstream response Cahe-Control headers.

The max-age and s-maxage directives are used to specify the maximum amount of time a response can be cached. The s-maxage directive is preferred over the max-age directive, when both are present in Cahe-Control.

Booster also adds an Age header to the response. The Age header is the time in seconds since the response was cached plus the value of the Age header in the response from the upstream (if it exists).

Cache-Status header

Booster adds a Cache-Status header to the response. The header follows the RFC-7234 specification.

Some examples of header values:

Response served from cache 
Cache-Status: Booster, hit
License is not configured for the app 
Cache-Status: Booster; fwd=bypass; detail=LICENSE
Session found for request 
Cache-Status: Booster; fwd=bypass; detail=SESSION
Response found in cache, but was stale 
Cache-Status: Booster, fwd=stale
Response not found in cache 
Cache-Status: Booster, fwd=miss

Contents

Contents