• Edge Application
• Edge Caching

Edge Caching is a module available for Edge Application that reduces latency in applications and increases transfer rates through Azion’s network of edge nodes.

When your content is successfully cached, also known as a cache hit, it can be directly delivered to your users from edge node nearest to them, eliminating the frequency of access to your origin servers. This not only enhances performance and scalability for your content, but also cuts back on infrastructure costs.

In the event of a cache miss, when the requested content isn’t available in the cache, Azion Edge Caching module minimizes the impact by maintaining a keep-alive connection with the origin server whenever possible. This approach avoids the overhead of frequent TCP/IP handshakes. Irrespective of the number of simultaneous requests made to Azion’s Edge Nodes, each edge node only needs to search the content from the origin once per cache miss, which reduces the load on your infrastructure.

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

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 the experience for your users, 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.

A cache key is an index entry for an object in Azion’s edge nodes. When a request is made to an edge 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 edge 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 through a request for the content URI and add the Azion debug header Pragma: azion-debug-cache:

curl -I https://yourdomain.com/resource-path/image.jpeg -H "Pragma: azion-debug-cache"

A successful response will return an X-Cache-Key header with the cache key value, which based on the example above, would be:

X-Cache-Key: httpsyourdomain.com/resource-path/image.jpeg@@

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.

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@@.

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.

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.

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.

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.

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

For example, for a file that is 2097151 bytes in size, if file slicing 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

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

With Edge Caching, you can customize both browser cache TTL (Time-to-Live) and edge 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 edge 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 edge cache TTL allows you to fine-tune your caching strategy based on your content’s update frequency, user traffic patterns, and overall performance objectives.

When your application’s cache expires, it becomes stale (obsolete) and the server searches the origin for the most up-to-date version. This new version, with an updated expiration date, overwrites the old one (stale).

However, the server may encounter problems and be unable to get the most up-to-date version of your application from the origin. When active, Stale Cache delivers the latest version of the content in cache, regardless of expiration, whenever origin servers are unavailable.

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.

Contributors