Contentstack CDN Cache Management

A Content Delivery Network (CDN) ensures that a cache of your content is stored at various locations around the globe. Consequently, whenever there is a page request, the content is served from the cache of the nearest CDN server, rather than the origin server ensuring quicker content delivery.

Additional Resource: Want to know more about how CDNs work? Here's an article on What CDN is and How it Works.

How CDN Cache Works in Contentstack

The CDN is always up-to-date. It ensures that the cache is always fresh through purging old data and caching new data.

When any user requests a piece of content, the nearest CDN server checks if it has a cached copy of the requested content. If not, it checks with the shield server. And, if the shield server does not have the cache of the requested content, it fetches the content from the origin server.

A shield server is an extra layer of caching that reduces the load on the origin server. It is located near the origin server, and it saves the cache of content that it serves to any CDN server. So, if any other CDN server requests the same data, the shield server would serve the cached content.

Additional Resource: Interested in learning how to set up your CDN for your Contentstack-powered websites? Refer to our guide on how to set up a Content Delivery Network for Contentstack-powered Websites.

This ensures that content is always available and delivered even in high visitor traffic, intermittent spikes and server outages, resulting in better customer experience and satisfaction.

Cache Purging

Purging refers to the removal of the cache from the cache servers. Contentstack purges cached data from the cache servers based on the occurrence of certain events.

When a piece of content is published, unpublished, or deleted, Contentstack purges the cache of only the changed content (and some other related content) from the Content Delivery Network (CDN) This ensures that the unchanged cache remains intact, and you hit fewer API requests to the origin server while fetching content.

The following table lists down the different circumstances under which cached content is purged from other cache servers:

Note: The cache of an item can stay on the cache servers for a maximum of 1 year. After that, it is purged automatically.

Determining the Timeouts and Retries for Content Delivery APIs

You can set up timeouts and retries for Content Delivery APIs for your app depending on the time our CDN takes to serve content.

• Requests served by the origin server
  After a purge event, the first request coming to the origin server will take more time than requests served from the cache. This however does not exceed one sec (for regular requests with limited references).
• Requests served from cache
  Once the call is cached in the CDN, it can be served in milliseconds. Hence, it is suggested to keep the timeout to as minimum as possible for the time taken by the origin server and three exponential requests on failure.

Understanding Cache Header Response

When you make a request to fetch content from Contentstack, the CDN response includes several headers that provide details about the cache status. Key headers include X-Request-Id, X-Served-By, X-Cache, and X-Cache-Hits. If you observe that your website is experiencing some delays in serving content, it might be a good idea to check if the content is being served from the CDN’s Point of Presence or POP server, shield server, or through Contentstack’s origin server.

An example of cache headers is given below:

X-Request-Id: cf5dc19b-485b-411e-aa3a-2f5229145e94
X-Served-By: cache-lxx8483, cache-axs21008-AMS
X-Cache: HIT, MISS
X-Cache-Hits: 1, 0

Let’s learn about these headers and what to infer from the possible values that you may get.

X-Request-Id

The X-Request-Id header provides a unique identifier for each request. This can be useful for debugging and tracking individual requests across the system.

X-Served-By

The X-Served-By header indicates the specific cache node (POP) that served the request. This helps identify which edge server handled the request.

Example:

X-Served-By: cache-{datacenter}{nodeid}-{datacenter}

This indicates that the edge node cache-{datacenter}{nodeid}-{datacenter} handled the request. This information is useful for analyzing the performance and distribution of requests across different nodes.

In some cases, X-Served-By may have two values, indicating that there may be more than one server identity listed, separated by commas.

X-Cache

The X-Cache header indicates whether the requested content was served from the cache and provides information on the cache state. Below are the possible values and their meanings.

• Example 1:
  X-Cache: MISS, MISS
  This indicates that the object was not in cache at either the edge or the shield and was fetched from the origin.
• Example 2:
  X-Cache: HIT, MISS
  This indicates that the object was not in cache at the edge but was found in cache at the shield.
• Example 3:
  X-Cache: MISS, HIT
  This indicates that the object was found in cache at the edge, and although it was previously a MISS at the shield.
• Example 4:
  X-Cache: HIT, HIT
  This indicates that the object was found in cache at the edge, and it was also a HIT at the shield during the prior fetch.
• Example 5:
  X-Cache: HIT
  This indicates that the object was found in cache at the POP which also acts as the designated shield.
• Example 6:
  X-Cache: MISS
  This indicates that the object was not in cache at the POP which also acts as the designated shield, so it was fetched from the backend.

X-Cache-Hits

The X-Cache-Hits header shows the number of times a specific edge node (within a POP) has served the requested content from its cache since it was last fetched from the origin server.

Note: The X-Cache-Hits value is specific to the edge node that served the request. It does not represent the total number of hits across all nodes in the CDN. For instance, if X-Cache-Hits is 0, it indicates that the content was served from the cache of that edge node for the first time since it was last fetched from the origin. Different edge nodes may show different X-Cache-Hits values for the same content. Each node maintains its own count based on the requests it handles.

Here are examples of X-Cache-Hits headers and their meanings:

• Example 1:
  X-Cache-Hits: 5
  This means that the edge node has served the requested content from its cache five times since the last origin fetch.
• Example 2:
  X-Cache-Hits: 0
  This means that the edge node has served the requested content from its cache for the first time since the last origin fetch.
• Example 3:
  X-Cache-Hits: 1, 0
  In some cases, X-Cache-Hits may have two values, involving both an edge node and a shield node. The 1, 0 response in this example means that the edge node has served the requested content from its cache once, and the shield node served it for the first time since the last origin fetch.

By understanding these headers, you can better interpret the CDN cache performance and ensure accurate reporting.