Real-Time Purge
Through Real-Time Purge you can instantly delete the cache of your content at Azion, using a Cache Key List, a URL List or a Wildcard expression that represents the objects you want to purge.
1. Content update strategies
When you update content at your origin, you must choose the best strategy for updating it in Azion’s cache. Here are the available options: expiration time, object names with version and Real-Time Purge.
Expiration time
When configuring your cache policy, you determine the amount of time you want your objects to be cached at Azion. When you update your content at the origin, Azion can continue providing a cached copy of it, for as much time as you have set it to be cached.
Objects name with version
We recommend, whenever possible, you use some versioning markup in an object name. When you update it at your origin, you can add the version in the object name, forcing each modification of your content to be treated as a new object by Azion.
Real-Time Purge
You can instantly delete the cache of your content at Azion, from either Edge Caching or L2 Caching. This way, Azion system fetches the latest version of your content in the origin.
Whenever possible, use cache policies with long expiration time for your content, such as 1 year – setting the Maximum TTL field to 31,536,000 seconds. This way, you will be optimizing the performance of your content or application, improving the experience for your users, reducing traffic with Azion and reducing the load at your origin.
To version your objects name, you can use a sequential number, a timestamp or other mechanism that you think is most appropriate as a version markup. For example, instead of naming an image as image.jpg, you could name it image_1.jpg and, when you need to update it, change the version to image_2.jpg.
This way, each content update will be treated as a new object by Azion, which guarantees you the following benefits:
- it allows you to control which object a request should return, even if the user has the previous version locally saved in the browser cache or in some intermediate cache. Even if Azion cache is removed, users can still access the old version of their local cache, until the expiration time elapses;
- versioning allows you to provide different versions of your objects to different users;
- it also simplifies the rollback process in case of problems with your update.
2. Real-Time Purge
By providing a fast and predictable purge operation, Azion enables you to increase the expiration time (TTL) of your cached objects, or cache event-drive objects, improving the offload and performance of your content or application, and also reducing your traffic with Azion.
By using Real-Time Purge to manage the cache expiration of your content, you can also perform:
- dynamic content caching and API responses, without sacrificing the user experience, as Azion’s Edge Caching and L2 Caching products will be updated with your latest content;
- better cache efficiency, ensuring greater control over how your objects are served by Azion;
- better and more predictable management of obsolete or outdated objects, helping your developers to build reliable, resilient and better performing solutions.
In addition, we provide two interface options for running object purge in Edge Caching and L2 Caching: via Real-Time Manager or via Azion API.
To access Real-Time Purge via the web, proceed as follows:
-
Access Real-Time Manager;
-
In the Products menu on the top left corner, go to Real-Time Purge in the Tools section;
-
Click the New Purge button, fill in the required fields;
Field Options Layer Edge Caching: Purge web content delivered at the Edge.
L2 Caching: Purge web content in the layer nearest to your origin.Purge Type Cache Key
URL
WildcardArguments www.example.com.br/index.html
Tip: separate arguments using new line. -
Click the Purge button to perform a purge for the chosen options.
You can remove content from both Edge Caching - to clean up web content that is delivered to the Edge - and L2 Caching - to clean up web content at the layer closest to your origin.
Note: All three purge options are available for the Edge Caching layer. For the L2 Caching layer, the Wildcard purge option is not yet available, that is, L2 Caching purge is available only through URL and Cache Key.
3. Types of Purge
You can run Real-Time Purge on either the Edge Caching or L2 Caching product by entering as a parameter the URLs list, a Wildcard expression, or the list of Cache Keys.
URL Purge | Cache Key Purge | Wildcard Purge |
---|---|---|
It is the simplest way to purge your content cache by passing a URL list of until 50 objects per request. You cannot purge content cache variations with this method. | It is the most accurate way to purge your content cache by entering a cache key list of until 50 objects per request. | It is a powerful way to purge a list of objects by entering a Wildcard expression. You can use the wildcard character (*) in path or query string arguments. |
See the details of each type of purge:
URL Purge
It allows you to purge cached objects, by entering a list of URLs as an argument. The URL format must respect the standard: scheme://host
or just host
, followed or not by a /path
and the ?query-string
. When hiding the scheme, both “http” and “https” contents will be purged.
A URL Purge is non-recursive, which means that only the URLs entered will be purged from the cache. The URLs are automatically converted to their respective Cache Keys, without considering any content variation in the same URL.
Content variations based on cookies, device groups, image format or others do not expire with this operation. Consider using Cache Key Purge or Wildcard Purge for these situations.
The expiration of content variations based on Query String can be run using URL Purge, since Query String is a component of the URL, as long as the arguments used for content variation are sent in the correct order in which they were presented. If you use the Query String Sort feature, either sort the arguments in the request, or consider using Cache Key Purge or Wildcard Purge as an alternative.
If you use the asterisk (*) character in a URL Purge request, it will be treated as a character in the URL and not as a Wildcard.
Examples of a URL Purge:
www.yourdomain.com
static.yourdomain.com/include/site.css
static.yourdomain.com/include/site.js
dynamic.yourdomain.com/app.py?argument
Cache Key Purge
It allows you to purge cached objects by passing a list of Cache Keys as an argument.
A Cache Key is an index entry for an object in Azion’s cache. The default cache key format adopted by Azion uses the URL host and path to identify objects. You can specify an advanced cache key to identify different variations of an object, based on:
- Query String or Query String Sort arguments;
- cookies – when using Azion Application Acceleration;
- image format according to browser support – when using Azion Image Processor).
To obtain the Cache Key, you must request the content using Azion Debug Header (Pragma: azion-debug-cache), for example:
HEAD /path HTTP/1.1 Host: yourdomain.com Pragma: azion-debug-cache
The response will return a header with the cache key (X-Cache-Key), for example:
X-Cache-Key: yourdomain.com/path@@
Each object variation is represented by a distinct cache key and is expired individually. For example, if there is an object variation per device group, each URL in each group will have a distinct Cache Key with the separator “@@
” and the device group name. To purge all variations, you must search for the cache key individually for each group.
Examples of Cache Key Purge:
www.yourdomain.com/@@
www.yourdomain.com/@@Mobile
static.yourdomain.com/include/site.css
static.yourdomain.com/include/site.js
static.yourdomain.com/static/images/image_1.jpg?ims=880x@@
static.yourdomain.com/static/images/image_1.jpg?ims=880x@@webp
Wildcard Purge
It allows you to purge cached object by giving a Wildcard expression as an argument. The Wildcard expression format must be according to the standard: scheme://host
or just host
, followed or not by a /path
and the ?query-string
, with an asterisk character (*) in the path or query string.
The Wildcard expression is automatically converted to multiple objects in the same domain. To expire the content variations based on cookies, device groups or image format, for the same URL, use the URL with the expression “@@ *
” at the end.
www.yourdomain.com/*
static.yourdomain.com/include/*.css
static.yourdomain.com/*/site.js
static.yourdomain.com/static/images/image_1.jpg?ims=*
dynamic.yourdomain.com/app.py@@*
You can even use multiple wildcards to select a complex pattern.
www.yourdomain.com/alpha*
www.yourdomain.com/*beta*
www.yourdomain.com/*a*/charlie
www.yourdomain.com/*a*/*a*
www.yourdomain.com/*?b*
www.yourdomain.com/*?*2*c=*
4. Purge methods
Delete
The Delete method removes the object from the cache. In the next user’s content request, an unconditional GET request will be made to the origin.
This purge method prevents Azion from delivering an outdated object (stale) if the origin is inaccessible. Instead, if the origin is inaccessible, an error page will be delivered.
The use of the Delete method is indicated for:
- removing content from Azion’s cache, after it has been removed from the origin;
- forcing the removal and later updating of contents for which the timestamp is unreliable;
- forcing the delivery of an error page instead of an outdated object (stale), if your origin is inaccessible and Azion is unable to get the latest version of your content.
5. Purge objects with content variation
Application Acceleration
When using cookie-based content variation, in addition to the host and path, the cache key will include the @@
separator followed by the name of the cookies used and values.
For example, for the same URL http://www.yourdomain.com/, using content variation based on the “user” cookie, the cache keys could be:
www.yourdomain.com/@@
www.yourdomain.com/@@user=user1
www.yourdomain.com/@@user=user2
To purge objects with cookie-based variation, you can use Cache Key Purge, entering all variations individually, or a Wildcard Purge, using @@*
at the end.
When using Query String based content variation, in addition to the host and path, the cache key will include the ?
separator and the query string arguments used. For example:
dynamic.yourdomain.com/product.py?id=1000
dynamic.yourdomain.com/product.py?id=1001
To purge objects with variation based on query string, you can use a Cache Key Purge, entering all the variations individually, or a Wildcard Purge, using ?*
at the end, or a URL Purge, entering in the URL only the arguments used in the cache key. If you use Query String Sort, the arguments must be sent in the correct order.
Image Processor
By using Image Processor, you will be using an advanced cache key. In addition to host and path, will the cache key include the separator?
and the product arguments, and the @@
separator for identifying image format variation supported by the browser.
Examples of cache keys using Image Processor:
static.yourdomain.com/static/images/image.jpg@@
static.yourdomain.com/static/images/image.jpg@@webp
static.yourdomain.com/static/images/image.jpg?ims=88x@@
static.yourdomain.com/static/images/image.jpg?ims=88x@@webp
To purge images processed by Image Processor, you can use a Cache Key Purge, entering all variations individually, or a Wildcard Purge, using *
at the end.
Slice Configurations
If you use cache optimization to deliver large files – sliced files – such as in Progressive Download media, you will be using an advanced cache key. In addition to host and path, the cache key will include the @@bytes=
separator, for each slice of content.
Examples of cache keys using optimization for delivering large files:
static.yourdomain.com/midias/file.mp4@@bytes=0-1048575
static.yourdomain.com/midias/file.mp4@@bytes=1048576-2097151
To purge objects using this optimization, you must use a Wildcard Purge, with @@*
at the end. You can also use the Cache Key Purge, as long as you enter the cache key for all slices correctly.
Be careful when you purge for a slice individually, because if there is a change of content at the origin, it may be inconsistent in the cache.
POST and HTTP Method
By default, Azion allows caching of GET and HEAD methods only. You can enable the POST or OPTIONS caching in the Cache Settings tab, in the Edge Applications settings, in which you will be using an advanced cache key. In addition to host and path, the cache key will include the @@ separator followed by the MD5 hash of the request body (POST arguments).
Synthax
Example POST method
dynamic.yourdomain.com/path@@md5_of_post_arguments
Example OPTIONS method
dynamic.yourdomain.com/path@@md5_of_options_arguments
To purge these objects, you can either use a Cache Key Purge, entering all variations individually or a Wildcard Purge, using @@* at the end.
Learn more: API - Real-Time Purge
Custom Configurations
If you have a Custom Configuration with a custom cache key, you must use the Cache Key Purge to delete the cache of your objects. In addition to host and path, the cache key may include the @@
separator followed by its custom arguments.
dynamic.yourdomain.com/path@@custom_arguments
You need to refer to the custom format of your cache key to run the Cache Key Purge.
6. Purge confirmation
The purge is an operation that does not require confirmation. Since the Real-Time Purge is completed almost instantly, no confirmation of the operation is required and you can expect your purges to be completed in less than 3 seconds, except in the case of consistent use of Rate Limits.
When needed, you can query the purging history to find out the user who made the request, the time, argument list, purge type and method.
7. Limits
The purge operation is performed according to the following usage limits, based on the type and number of objects that are being purged:
- URL and Cache Key Purges: up to 10,000 objects every 60 seconds, up to 200 requests with 50 objects per request, per client. The URL and Cache Key are limited to 4,096 characters.
- Wildcard Purges: up to 2,000 requests per day (per 24h interval), one Wildcard URL per request. The Wildcard URL is limited to 256 characters.
- Purging history is limited to 6 months and up to 1 million requests.
Didn’t find what you were looking for? Open a support ticket.