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.
ImplementationSection titled Implementation
|Available cache settings||Cache Settings|
|L2 Caching module||L2 Caching|
|Configuring a cache policy||How to configure cache policies for Edge Application|
Cache keysSection titled Cache keys
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
A successful response will return an
X-Cache-Key header with the cache key value, which based on the example above, would be:
Cache key formatSection titled Cache key format
The default cache key format adopted by Azion concatenates the following URI syntax elements:
- Scheme of the request
- 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
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
Complex requestsSection titled Complex requests
If the resource is obtained using a complex request (any method different than
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
Image ProcessorSection titled 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
Device GroupsSection titled 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
Advanced Cache KeySection titled 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:
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
city could generate the following cache keys:
For multiple query strings, if Query string sort is enabled, the query strings will be grouped under the same cache key, ordered alphabetically.
File slicingSection titled File slicing
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:
Cached HTTP methodsSection titled Cached HTTP methods
OPTIONS requests, the cache key appends the
@@ separator followed by the MD5 hash of the request body.
Expiration settingsSection titled Expiration settings
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.Learn more about expiration settings
Stale cacheSection titled Stale cache
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.Learn more about stale cache
Adaptive DeliverySection titled 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.Learn more about Adaptive Delivery