Intro to TTL Management - Part 2

In the first part of this series on managing dynamic CDN content, I explained how to use direct cache invalidation for caching dynamic content. In this second part, I’ll address TTL management as a method for meeting the particular challenges presented by dynamic content and CDNs.

TTL (time to live) management is by far the most practical and widely supported way to cache dynamic content. When properly used, dynamic content can be configured to have sub minute responsiveness without propagating an excessive amount of origin traffic and bandwidth usage.

The first step in proper TTL management is understanding the standard HTTP 1.1 RFC caching headers: Cache-Control, Age, ETag, and Last-Modified. Legacy headers like Pragma and Expires (HTTP 1.0 headers) have been superseded by the above headers and can be safely ignored.

RFC Header Explanation

Cache-Control is a pretty straightforward header. Simplistically, it defines if the resource is cacheable or not cacheable. If it is cacheable, it defines for how long. Note that the how long part, max-age, is a relative time defined in seconds.

Example:

Cache-Control: public, max-age=86400

More details can be found in the HTTP 1.1 Cache-Control specification.

The Age header states how old a resource is relative to its max-age lifespan. So if a resource has a max-age of 300 seconds and was requested two-thirds of the way thru that lifetime, it would have an Age of 200 seconds.

Example:

Cache-Control: public, max-age=300

Age: 200

The TTL is calculated by subtracting the max-age from the Age. So in this case, the resource’s TTL is 100 seconds. The TTL of a fresh object is its max-age since the Age is effectively 0.

Note that misuse or omission of the Age header can result in TTL skew. Worst case, it can cause your TTL to double for every caching layer your content goes thru.

The Etag and Last-Modified headers allow a requester to ask if a particular page has been updated. This is done via a If-None-Match and If-Modified-Since conditional request. These requests allow the server (or caching layer) to respond with a 304 Not Modified response, which is generally a quick and efficient lookup and single packet response.

Varnish Cache supports all RFC caching headers, aging, and conditional requests.

In the next installment, we will put it all together into an effective Varnish Cache strategy.

Learn much more about Varnish Cache - download the book.

Photo (c) 2016 Peter Trimming used with Creative Commons license.