• Build
• Edge Application
• Edge Cache

Edge Cache is a module available for Edge Application 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 Edge Cache can also serve cached content to your users from the edge.

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 Edge 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 edge 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:

X-Cache: HIT from 200.000.000.00 with HTTP/2.0

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 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:

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.

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

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

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 Cache, 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.

Stale Cache ensures the delivery of content when a direct request to origin servers return an error, the request suffers a timeout, the server headers are invalid, or the file is undergoing an update. Instead of serving an error to users, the edge node scans for a valid cache entry and delivers it, even if it’s expired.

When Stale Cache is disabled and the server is unable to update the cache from the origin, the application will return a 5xx error to the user.

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 is a resource for Edge Application 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.

These are the default limits:

Contributors