Cache variation
What Application Accelerator unlocks, what each cache variation costs, how purges reach varied objects, and how a TTL of 0 differs from Bypass Cache.
When the response to one URL depends on a cookie, a device, or a request body, the cache has to tell those requests apart. On an application, one switch turns on Application Accelerator, and a cache setting then names the inputs that make two requests different. How a variation changes the cache key, with its diagram, is on How Applications works.
The sections cover what the switch unlocks, what a variation costs, how purges reach variations, and how Bypass Cache differs from a TTL of 0.
What Application Accelerator unlocks
Turning on Application Accelerator unlocks four capabilities that look unrelated until you see what they have in common:
- Cache variation beyond the URL, by query string, by cookie, by device group, and by request method. The feature is named Advanced Cache Key.
- Caching of
POSTandOPTIONSresponses, beyond theGETandHEADresponses an application caches natively. - A Max Age as low as 0 seconds, under the 60-second floor that holds without it.
- Seven more Rules Engine behaviors, and the
${request_uri}and${device_group}variables in rule criteria. The behaviors are Add Cookie, Bypass Cache, Capture Match Groups, Filter Request Cookie, Forward Cookies, Rewrite Request, and Run Function.
What the four have in common is dynamic content. Cache variation gives the cache key the extra input it needs to tell two correct responses apart. Caching POST and OPTIONS brings in the methods that carry that input in the request body. A TTL under a minute fits content that stops being correct before a minute passes. Several of the gated behaviors act on the cookies and paths that carry the difference in the first place.
The switch is all four or none. An application cannot take cache variation without also taking the extra methods and behaviors. A cache setting that sets a variation on an application with the switch off is refused with 21013.
Turning the switch on changes no traffic by itself, either. The query-string, cookie, and device controls of a cache setting start at ignore, and the method list starts empty. A cache setting reaches a request only when a Set Cache Policy behavior applies it.
Turning on a Product can generate usage-related costs. For more information, refer to Pricing.
The cost of a variation
Cache variation has one cost, and it follows from how the key is built: each distinct value of a varying attribute produces a separate cached object. That makes the choice of what to vary by more consequential than the choice to vary at all. A cookie whose value is unique to each visitor gives every visitor a copy of the object. The cache still works, but it no longer serves one stored response to many requests, and the number of objects grows with the audience instead of with the content.
An allowlist is the control for that cost. The allowlist behavior names the query-string arguments or the cookies that change the response, so an attribute nobody named cannot create another object. The all behavior varies by every attribute that arrives, including the ones the application ignores. For example, a link that arrives with a campaign argument gets its own cached object under all. Under an allowlist that does not name that argument, the same link maps to the shared object.
Sorting applies the same economy to the order of the arguments. The chosen arguments enter the key in the order the request submitted them, so ?a=1&b=2 and ?b=2&a=1 are two objects that hold one response. With Sort on, those variations group under one key, ordered alphabetically. For example, a product listing that changes with its category and page arguments names both in an allowlist. With Sort on, every order of the two arguments reaches one object. The cost of sorting is that the key no longer matches the URL as the client wrote it, which matters at purge time. For the Console steps that set these controls, refer to Configure Advanced Cache Key for an application.
Cache variation and purges
A purge removes an object from the cache, and it finds the object by its cache key. A URL purge converts the URL it receives to a cache key without considering content variation. Every variation that the URL does not carry therefore survives it. Cookie variations and device group variations do not expire with a URL purge, and their copies stay in the cache.
Two purge types reach them. A cache key purge names each variation, and a wildcard purge ends the key with @@*. Query-string variations are the exception, because the query string is part of the URL. A URL purge reaches them when the arguments are sent in the order they were presented, or in alphabetical order when Sort is on.
The variations you configure are also the objects a purge has to reach. A variation with many distinct values therefore costs you at purge time as well as in storage. For the purge types and the steps to run each one, refer to Real-Time Purge.
Bypass Cache and a TTL of 0
Without Application Accelerator, the shortest Max Age an application accepts is 60 seconds, and the API refuses a lower value with 21021. Application Accelerator removes that floor and allows 0 seconds, or 3 seconds when the cache setting also has Tiered Cache on. A TTL of 0 is not the same as not caching, and the difference between the two is why both exist. Both need Application Accelerator, because Bypass Cache is one of the behaviors it unlocks.
The Bypass Cache behavior sends every HTTP and HTTPS request its rule matches to the origin, and Azion caches nothing in its own cache. It keeps protocol optimizations and, where possible, a keep-alive connection to the origin. It does not change the browser cache, which a Set Cache Policy behavior sets. It does not reach the Tiered Cache layer either: an application with active Tiered Cache settings keeps caching objects there for the minimum TTL. Use it when each request has to receive different content.
A Max Age of 0 seconds keeps the request on the cache path. Parallel requests for the same object reach the origin as one request, and Azion validates the object with an If-Modified-Since request. An object that has not changed is not transferred again, and the answer can be a 304 Not Modified. A Max Age of 0 still creates a cache object, which lives for 999 milliseconds. Use it when dynamic content can be delivered identically to everyone who requests it at the same moment.
The trade is between freshness for each request and load on the origin. Bypass Cache gives every request its own answer, and gives up both the single origin request for parallel requests and the revalidation that skips an unchanged transfer. A TTL of 0 keeps both, and gives up the ability to answer two simultaneous requests differently.