Cache

Cache is a module available for Applications that allows you to configure how your application caches content, reducing latency and increasing transfer rates through Azion’s network of edge nodes. This not only enhances performance and scalability for your content but also cuts back on infrastructure costs.

With Azion, you can customize the time the cache remains in the edge through time-to-live (TTL) values. Cache policies with large TTL values can optimize the performance of your application, improving user experience, reducing traffic with Azion, and reducing the load at your origin. However, a low cache TTL can help you ensure end-users always see the most current information.

If origin servers experience downtime or become unavailable, Azion Cache can also serve cached content to your users from the edge.

Implementation

Cache status

Azion provides a layer to cache content in the edge network, which stands between origin servers and the end user. When content is successfully cached at the edge, it receives a cache status HIT and it can be directly delivered to your users from the edge node nearest to them, reducing the frequency of access to origin servers.

When the requested content isn’t available in the cache, the Azion Cache module employs strategies to minimize the impact on the origin server and optimize content delivery. One of these strategies includes maintaining keep-alive connections with the origin server whenever possible, to reduce the overhead associated with frequent TCP/IP handshakes. This is particularly effective during cache updates or in situations of a cache MISS.

Additionally, Azion implements Thundering Herd control to ensure that, in the face of multiple simultaneous requests for the same non-cached object, only one connection is established with the origin server. This approach ensures that each of Azion’s edge nodes request content from the origin server only once per MISS or other non-HIT statuses, thereby optimizing network efficiency and reducing the load on the origin server.

You can obtain the cache status of an application’s resource by requesting the content URI and adding the Azion debug header Pragma: azion-debug-cache. A successful response will return an X-Cache header with the cache status, the IP of the edge node, and the protocol used in the request:

Status definitions

Cache keys

A cache key is an index entry for an object in Azion’s edge nodes. When a request is made to an application for the first time, the edge forwards the request to the origin server and generates a cache for each object received at the edge. When the next request for the same resource is made to the application, if the resource requested matches one already found through the cache key, the request won’t be forwarded to the origin.

You can obtain the cache key of an application’s resource by requesting the content URI and adding the Azion debug header Pragma: azion-debug-cache. A successful response will return an X-Cache-Key header with the cache key value:

Cache key format

The default cache key format adopted by Azion concatenates the following URI syntax elements:

• Scheme of the request
• Host
• Path to the resource
• Query strings
• A variation separator and, when implemented, appended variations

An object with the URI https://static.yourdomain.com/page/site.js should generate the cache key httpsstatic.yourdomain.com/page/site.js.

Cache keys are case sensitive, meaning upper and lower case characters are considered as distinctive.

Some cache keys may also change depending on variations generated at the edge. If variations are enabled, the cache key may contain the @@ separator at the end, resulting in httpsstatic.seudominio.com/pagina/site.js@@.

Complex requests

If the resource is obtained using a complex request (any method different than GET or HEAD), the method is added to the start of the cache key.

For example, for an OPTIONS request, the cache key generated for an object would be optionshttpsstatic.yourdomain.com/page.

Image Processor

When Image Processor is activated, in addition to the ims query string, variations with converted format contain the file format after the separator.

For example, for an image that is resized and converted into webp format, the cache key generated will be httpsstatic.yourdomain.com/static/images/image_1.jpg?ims=880x@@webp.

Device Groups

If there’s an object variation per device group, the cache key will be appended with the separator @@ and the device group name

For example, for an application that implements variation for the Mobile group, the generated cache key will be httpwww.yourdomain.com/@@Mobile.

Advanced Cache Key

When the Advanced Cache Key feature is configured, the formation of cache keys is also affected.

Cache by Cookie generates a cache key variation with the determined cookie names and values followed by ;.

For example, content variation based on the user cookie could generate the following cache keys:

• httpwww.yourdomain.com/@@;
• httpwww.yourdomain.com/@@user=user;

Cache by Query String generates cache keys with the query separator and the determined arguments based on the order of the query strings submitted in the request.

For example, content variation based on name and city could generate the following cache keys:

• httpstatic.yourdomain.com/page?name=name
• httpstatic.yourdomain.com/page?city=city&name=name
• httpstatic.yourdomain.com/page?name=name&city=city

For multiple query strings, if Query string sort is enabled, the query strings will be grouped under the same cache key, ordered alphabetically.

Large File Optimization

For fragmented objects, the cache key appends the @@bytes= separator for each piece of content.

For example, for a file that is 2097151 bytes in size, if this feature is enabled, the cache keys generated will be:

• httpstatic.yourdomain.com/media/file.mp4@@bytes=0-1048575
• httpstatic.yourdomain.com/media/file.mp4@@bytes=1048576-2097151

Cached HTTP methods

For cached POST or OPTIONS requests, the cache key appends the @@ separator followed by the MD5 hash of the request body.

For example:

• httpsdynamic.yourdomain.com/path@@md5_of_post_arguments
• httpsdynamic.yourdomain.com/path@@md5_of_options_arguments

Expiration settings

With Cache, you can customize both browser cache TTL (Time-to-Live) and cache TTL according to your specific requirements.

By setting your TTL for browser cache, you can control how long the content remains stored on local browsers. A longer TTL can reduce the need for users to fetch content from the edge or origin servers, improving load times and reducing bandwidth usage.

You can also define how long your content should remain cached on Azion’s edge nodes. A longer cache TTL can enhance content delivery performance, as frequently accessed content remains available closer to users, reducing the load on the origin server.

Striking the right balance for cache expiration times is crucial to ensure users receive the most up-to-date content without serving stale cache for too long.

The ability to customize both the browser cache TTL and cache TTL at the edge allows you to fine-tune your caching strategy based on your content’s update frequency, user traffic patterns, and overall performance objectives.

Stale cache

Stale Cache lets Azion edge nodes keep serving your users previously-cached objects even after they expire, avoiding downtime or error pages while fresh content is fetched from your origin.

How it works

1. When Enable Stale Cache is turned on in a Cache Setting, every response stored in the cache at the edge is allowed to be reused if a revalidation attempt fails because of:

   • 5xx errors returned by the origin.
   • Connection time-outs or origin unreachability.
   • Invalid or missing cache-control headers.
   • The object being updated (revalidation in progress).

2.The edge node first looks for the stale-while-revalidate=<ttl> directive:

• Honor Origin Cache – If enabled and the origin supplies stale-while-revalidate, that value defines how long the object may be served stale.
• Override Cache Settings – If this mode is selected or the origin omits the directive, Azion automatically assigns a default stale window of 300 seconds (5 minutes).

3. During the stale window the edge node serves the expired copy immediately and asynchronously fetches a fresh version in the background. When the new object is stored, subsequent requests receive the updated content.

Adaptive Delivery

Adaptive Delivery detects device groups you’ve created using Device Groups, allowing you to configure how Azion delivers your content. You may choose to deliver the same version of the content, regardless of device detection or keep device-based variations of objects in cache.

Large File Optimization

Large File Optimization is a resource for Applications that processes large amounts of data more effectively, reducing latency and saving bandwidth.

When enabling this functionality, large files are fragmented into smaller ones. These fragments are gradually delivered to the end user according to data consumption, avoiding an abrupt data transfer that could be interrupted by the user. This feature caches data on demand at the moment the user requests it, initiating the cache operation.

Limits

These are the default limits: