Application Acceleration is an Edge Application module that speeds up web applications and APIs through protocol optimizations and manages dynamic content requirements. This module enables the Advanced Cache Key functionality, as well as new options to customize your rules using Rules Engine, and provides support for HTTP methods.
1. How it works
Application Acceleration is an Edge Application module that optimizes protocols and manages the different requirements of static and dynamic content in order to accelerate the performance of web applications and APIs.
By keeping processes within Azion’s edge nodes, Application Acceleration can help you increase the performance of APIs and decrease the complexity of the infrastructure at the backend.
With Application Acceleration, you can:
- Create advanced rules in Rules Engine for HTTP request and response phases.
- Use the Advanced Cache Key functionality to customize cache policies for dynamic content based on cookies or query strings.
- Enable support for POST, PUT, PATCH, and DELETE methods for Edge Application, as well as the natively supported GET, HEAD and OPTIONS methods.
- Customize CDN cache TTL to values under 60 seconds.
2. Advanced Cache Key
By default, Azion considers each URL as a distinct object in cache. The Advanced Cache Key feature allows you to create advanced cache rules based on two options: Query Strings and Cookies. If needed, you can use both options simultaneously to define the content segmentation of your application.
See the guide on How to configure Advanced Cache Key for Edge Application.
2.1. Cache by Query String options
At Azion, you define how you want the content to be cached according to Query String variations in your URLs:
Content does not vary by Query String (Improves Caching): defines that the cache key must ignore the Query String. That is, two URLs that are different just by the variation of the Query String will be considered as the same cached object. For example,
http://yourdomain.com/path?queryBwill deliver the same cache content to your users.
Content varies by some Query String fields (Whitelist): you can list which Query String fields should be considered to differentiate between objects in the Azion cache. All other fields will be ignored. For example, if you list the
cityfield, the URLs
http://yourdomain.com/path?city=A&name=Ywill be considered as a single object in cache, while URLs
http://yourdomain.com/path?city=B&name=Xwill be considered as different objects.
Content varies by Query String, except for some fields (Blocklist): you can list which fields in the Query String should be ignored when differentiating cached objects. All other fields will be considered. For example, if you list the
randomfield, the URLs
http://yourdomain.com/path?city=B&random=123will be considered different object in cache, while
http://yourdomain.com/path?city=A&random=456will be considered as the same object in cache.
Content varies by all Query String fields: defines that the cache key must consider all fields of the Query String. That is, two URLs distinct by the variation of the Query String will be considered as two distinct objects in the cache. For example,
http://yourdomain.com/path?queryBwill be stored as separate objects in the Azion cache.
In order to increase caching efficiency, you can enable the Query String Sort option. If activated, it orders all the fields of the Query String, making the position of the fields irrelevant in the definition of the cache key. If the position of the fields is relevant to differentiate your content, you should disable this option.
2.2. Cache by Cookie options
You can also distinguish objects in the Azion cache by name/value of cookies.
Content does not vary by Cookies (Improves Caching): differentiates objects in Azion’s cache through URL; doesn’t take cookies into account.
Content varies by Cookies, with the exception of a few (Blocklist): you can list the name of the cookies you want to ignore in the cache key setting, considering all cookies except those listed.
Content varies by all Cookies: in addition to the URL, it considers all cookies to differentiate objects in Azion’s cache.
Tip: use this feature to segment your content by user profile, browsing session, access region, or according to your content targeting needs.
3. Bypass Cache
You can also use Azion to deliver your dynamic and personalized content, even when some of your content can’t be cached in Azion’s infrastructure. At Azion, you define cache rules per path. You can create a Bypass Cache rule for the paths of your website that won’t be cached in our infrastructure.
By using Bypass Cache, you’ll configure Azion’s service to forward all requests to a path directly to their origin. However, you’ll count on important protocol optimizations to speed up your application and a keepalive connection between Azion edge nodes and their origin whenever possible.
See the guide on How to configure cache policies for Edge Application for more information on Bypass Cache.
3.1. Difference between Bypass Cache and TTL 0
While both the Bypass Cache behavior and Maximum TTL at zero seconds allow you to optimize content delivery and reduce load times at the origin, their effects are a bit different.
By using the Bypass Cache behavior, all HTTP and HTTPS requests received by Azion’s edge nodes will be sent to the origin, without caching any content. Use Bypass Cache if you want to deliver different content for each user request.
However, when setting TTL to 0 (zero) seconds, multiple requests in parallel to Azion’s edge nodes will be sent as a single request to their origin. In this case, Azion’s edge nodes also validate changes to the content with its origin by using the If-Modified-Since parameter. If the object hasn’t changed since the last request, the content won’t need to be transferred again, which could result in a much faster 304 Not Modified response. Also, setting maximum cache TTL to 0 will still generate a cache object that lives for 999 milliseconds.
Tip: you can set TTL to zero if the dynamic content, which varies from time to time, can be delivered identically to all users who make simultaneous requests.
4. Forward Cookies
If your origin manages application cookies, you may need the Forward Cookies functionality. By default, Azion filters the Response Header
Set-Cookie sent by the origin. If you wish, you can configure Azion so that
Set-Cookie is passed on to your users.
By using the Forward Cookies functionality, you’re determining that Azion forwards the
Set-Cookie header received from your origin, even in a cache hit. To prevent a user from receiving another user’s
Set-Cookie session, you must list all session cookies (private cookies) your application must ignore using the Advanced Cache Key.
See the guide on How to configure cache policies for Edge Application for more information on Forward Cookies.
An alternative to sending the response header
name=value and, optionally,
document.cookie = “username=John Doe; expires=Thu, 18 Dec 2020 12:00:00 UTC; path=/”;
By default, Azion won’t filter the Request Header
5. Support for HTTP methods
After you enable Application Acceleration for your application, you’ll be able to use POST, PUT, PATCH, and DELETE HTTP methods, in addition to GET, HEAD, and OPTIONS, which are already natively supported.
Didn’t find what you were looking for? Open a support ticket.