Expiration and freshness

How long a cached copy answers for the origin decides how fresh a response is and how often the origin is asked. On an application, a cache setting decides that time and what happens after it, and a purge ends a copy early. How a request reaches a cached copy, with the diagram of the cache path, is on How Applications works.

The sections cover TTL and expiration, stale cache, Large File Optimization, cache keys and variations, Tiered Cache, and purge.

TTL and expiration

A cache setting carries two TTLs. The browser TTL controls how long a visitor’s browser keeps its copy, and the cache TTL controls how long Azion keeps its own. A request the browser answers from its copy never reaches Azion, and a request Azion answers from its copy never reaches the origin.

Where each TTL comes from depends on the behavior the setting selects. In the Cache section, Honor cache policies keeps the Cache-Control and Expires headers the origin sends and forwards them to the browser, so the origin decides how long its content lives. Override cache behavior replaces those headers for Azion’s cache with the value of Max Age. The Browser Cache section carries its own choice for the browser’s copy: Honor cache policies, Override cache settings, or No cache. When the origin sends no TTL under Honor cache policies, Azion keeps the copy for a default TTL.

The copy expires when the cache TTL ends, and the next request for the object goes to the origin. When the origin returns the object, that response updates the copy, and the response reports EXPIRED. A check with conditional headers can also find the copy unchanged. The response then reports REVALIDATED, and the origin does not transmit the object again.

The TTL is a trade between the load on the origin and the age of what a visitor sees. A long TTL answers more requests from the copy and reaches the origin less, but content the origin already changed stays in the copy until it expires. A short TTL keeps the copy close to the origin’s version, at the price of more origin fetches. For example, one application can hold two cache settings, each applied by its own rule. Images that rarely change take a TTL of a day, and a listing that changes through the day takes a TTL of a few minutes.

Max Age has a floor and a ceiling. Without Application Accelerator, the floor is 60 seconds, and Application Accelerator lowers it. For every TTL bound, refer to Applications limits. For how a TTL of 0 seconds differs from bypassing the cache, refer to Bypass Cache and a TTL of 0.

Stale cache

A copy past its TTL still has a use. With Stale cache on in the cache setting, Azion may reuse an expired copy when a revalidation attempt fails for one of four reasons:

• The origin returns a 5xx error.
• The connection times out, or the origin is unreachable.
• The cache-control headers of the origin are invalid or missing.
• The object is under update, with a revalidation in progress.

How long the expired copy may be served is the stale window. Under Honor cache policies, the window is the value of the stale-while-revalidate=<ttl> directive the origin supplies. Under Override cache behavior, or when the origin omits the directive, the window is 300 seconds. During the window, the data center serves the expired copy at once and fetches a fresh version in the background. Once the new object is stored, later requests receive the updated content.

The response says which case applies. A response served from an expired copy because the origin failed to respond reports STALE. A response served while the fresh version is on its way from the origin reports UPDATING.

Stale cache shows visitors an old page instead of an error page during an origin outage, for as long as the window lasts. The cost is freshness: a visitor inside the window can receive content the origin already replaced. A change that every visitor has to see at once is therefore a case for a purge rather than for expiry.

Whether a new setting starts with the toggle on depends on the interface. A setting created through the API or the CLI has stale cache off, and Azion Console turns it on for a new setting. For the field, refer to Cache settings.

Large File Optimization

A large object can be cached in fragments rather than as one piece. With Large file optimization on in the cache setting, Azion splits the file into fragments of 1,024 kB. Each fragment is delivered as the user consumes it, and it is cached on demand, at the moment it is requested. The cache key of a fragment ends in @@bytes= and the byte range the fragment holds, so every fragment is an object of its own.

For example, a video of 2,097,151 bytes at https://static.example.com/media/file.mp4 becomes two fragments. They are stored under these keys:

A fragment is fetched only when a user reaches it, so a download that stops partway leaves the later fragments unfetched. The fragments that were fetched stay cached for the next request. The fragmentation applies to Azion’s cache, and to the Tiered Cache layer when the setting has that toggle on.

The cost comes at purge time. One file becomes many keys, so a purge lists the key of each fragment, or uses a wildcard that ends the path of the file with *. A purge that removes some fragments and not others leaves a mix of new and old fragments in the cache. For the purge types, refer to Real-Time Purge.

Cache keys and variations

A variation is a second copy of one URL, stored under a different cache key. While no variation is on, one path is one stored object. Azion builds the default key from the scheme, the host, and the path of the request. The query-string control of a cache setting starts at ignore, which keeps the query string out of the key. When something other than the path changes the response, the cache setting names it, and the key carries a marker for it.

Four inputs can vary a copy through the Application Accelerator section of a cache setting: a query-string argument, a cookie, the device group a request falls in, and the request method. Two more come from elsewhere. Image Processor adds the image format when it converts an image, and Large File Optimization adds the byte range of each fragment. Each distinct value is a separate key, so each one is stored and purged separately.

Device groups come from the Device Groups tab of the application, which Device Groups documents. With Cache vary by Devices, a setting either delivers one version whatever the device, or keeps a copy for each group it names.

The method is a variation too. GET and HEAD responses are cached natively, and POST and OPTIONS responses are cached only with Application Accelerator on. The request body then becomes part of the key as an MD5 hash, so two different bodies posted to one path are two objects.

A variation splits the requests for one URL across several copies. Fewer requests find a copy already present, and a purge has to reach every copy. For example, a listing page that varies by a page argument stores one copy per page number, and a purge of the listing has to name each of them. For the marker each variation appends, refer to Cache keys. For the controls that turn a variation on, refer to Application Accelerator settings.

Tiered Cache

Tiered Cache adds a second cache layer between Azion’s cache and the origin. When the data center that received a request holds no valid copy, it asks the Tiered Cache layer before it asks the origin. A miss in the first layer can therefore still be answered from cache, and the second layer keeps objects longer than the first.

The layer is turned on per cache setting with the Tiered Cache toggle, and every plan includes it. The setting names one of three topologies, the region that holds the layer: nearest-region, br-east-1, or us-east-1. Tiered Cache also requires Override cache behavior, because the API refuses it under Honor cache policies with 21001.

The trade is an extra hop and a floor on the TTL. A miss in the first layer travels to the second before it reaches the origin. A setting with Tiered Cache on also carries a minimum TTL, because the layer is designed for objects that stay cached a long time. In return, fewer requests reach the origin. For the minimum, refer to Applications limits.

A Bypass Cache rule affects Azion’s cache and not the Tiered Cache layer. An application with active Tiered Cache settings keeps caching objects in that layer for the minimum TTL. The layer is purged by cache key. When you purge an object held in both layers, purge the Tiered Cache layer first and then Cache, or the first layer refills from stale Tiered Cache content. For the purge layers, refer to Real-Time Purge.

Purge

A purge removes a stored copy before its TTL ends. The next request for the object finds no copy and goes to the origin, the response reports MISS, and the version the origin returns is stored. A purge is queued after you confirm it, because the result takes time to propagate. It appears in the purge history once it completes across Azion’s infrastructure.

A purge finds an object by its cache key, so the purge type matters for an object that varies. A URL purge converts each URL to a cache key without considering content variation. A copy that varies by cookie, device group, or image format therefore survives it. A cache key purge names each variation, and a wildcard purge reaches every key that matches an expression with *. Query-string variations are the exception a URL purge does reach. The arguments have to be sent in the order they were presented, or in alphabetical order when Sort is on.

Removing an object with the DEL HTTP method instead of a purge also makes the first GET request of a user go to the origin. The difference is the safety net. The method keeps Azion from delivering a stale copy when the origin is inaccessible, and an error page is delivered instead. It suits three cases:

• Content left the origin and has to leave the cache too.
• Content whose timestamp is unreliable needs a forced removal and a later update.
• An error page is preferable to a stale copy while the origin is unreachable.

A purge is the tool for a change that cannot wait for the TTL. Its cost is the origin fetch that refills each purged key, and the more keys an object has, through variations or fragments, the more a purge has to name. For the purge types and their arguments, refer to Real-Time Purge. For the steps, refer to Purge cached content.

Related resources