Akamai Diversity

The Akamai Blog

Dynamic Content: A Short TTL as an Alternative to Purge?

Purging URLs at the Edge when its underlying content changes at the origin infrastructure may seem to be the best way to manage a website dynamic content. Or is it?

In this post, we'll explore the pros and cons of purging, and offer an alternative when appropriate.
Purge¹ is a convenient way to ensure that whenever a piece of content is updated at the origin infrastructure, its cached versions get removed/invalidated at the Edge. It therefore 'guarantees' that from the point of the purge on, end users only get the latest content. Use cases range from updating css/js after a code release, posting new image instances produced by a CMS, or guaranteeing the freshness of a landing page (a.k.a. html page).

While it does achieve its goal in a majority of cases, it is wise to keep in mind that in real life, we've observed some pitfalls that can make the process far from ideal:

  • Over-purging: For convenience and simplicity, entire directories get routinely purged at a time, even if a small portion of the content actually changed. This leads to a great increase in the number of purge requests and additional, unnecessary traffic, between the edge servers and the origin, just to check that few resources actually changed!
  • SPOF: It relies on a process that can become a single point of failure
    • From the requestor side, all purge API calls must be coded and synchronized with CMS whenever content changes, and results verified for possible errors
    • From the provider side (CDN), purge API availability and execution time may vary
  • Flexibility: The purging infrastructure may not have the same level of control on caching parameters as the Edge servers may have

So what's the alternative?

Even so-called dynamic resources can typically bear some staleness. If the content is cached at the Edge with a short TTL, we can then guarantee acceptable content freshness without incurring the risks associated with the purge process explained above. The main potential downside of reducing a resource Edge cache TTL though is the negative impact it may have on the origin offload, so it is important to understand the relationship between the two.

We graph below representative Edge cache hit rates (= offload) as a function of the TTL, given a particular resource request rate, as observed on the Akamai platform in the US:

TTL Blog Post Image.png Note: The real offload observed by the origin can be significantly higher, since the graph only reports the Edge hits for simplicity. Akamai CDN for instance leverages a cache server hierarchy that increases further the origin offload. Also these graphs represent the typical patterns we observe. Individual resource traffic behaviors may not always conform to them. 

From this graph, we readily see that for popular content a short TTL (< 5 min) may yield significant (> 80 %) offload numbers and alleviate the purging/invalidation process altogether.

For lower request rates, it unsurprisingly would take a longer TTL to achieve respectable offload values. However for these unpopular resources, the offload is generally not a big concern.

To summarize, before making the decision to purge to ensure freshness of your dynamic content, give caching-with-a-short-TTL a try!

If you need additional information and best practices about caching, please consult:

¹ The term 'purge' in this post actually encompasses 2 different possible actions:
  • Actual physical purge of the object at the Edge, forcing a refetch of the resource (thru an http 200) as soon as a request arrives at the Edge
  • Content invalidation whereby a IMS (If-Modified-Since) is sent to the origin, which will only return the http headers (thru a 304) if the content did not change, or a full load (http 200) if the content needs indeed to be refreshed. This is the preferred method as it can alleviate a lot of unnecessary transfer from the origin to the edge servers whenever content hasn't changed