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, thatHEAD
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.), except for/_/component/
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 withprivate
,no-cache
orno-store
directive(s). -
Does not contain an
Expires
header. (Note: Any value ofExpires
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 istext/html
andtext/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 cacheablePatterns
)
-
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:
-
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
-
-
Cache for a single item is automatically cleared when
-
Cache item reaches Time to live (TTL)
-
-
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:
Cache-Status: Booster, hit
Cache-Status: Booster; fwd=bypass; detail=LICENSE
Cache-Status: Booster; fwd=bypass; detail=SESSION
Cache-Status: Booster, fwd=stale
Cache-Status: Booster, fwd=miss