1 of 20
2 of 20
3 of 20
4 of 20
5 of 20
6 of 20
7 of 20
8 of 20
9 of 20
10 of 20
11 of 20
12 of 20
13 of 20
14 of 20
15 of 20
16 of 20
17 of 20
18 of 20
19 of 20
20 of 20

site

doc

blog

success stories

Edge Caching

Edit on GitHub

Speed up the delivery by keeping your content cached at the edge of the network, closer to your users.

Edge Caching is a standard module for all of your edge applications at Azion. This product reduces the latency and has a high transfer rate through Azion’s highly distributed global network.

  1. How it works
  2. Cache Settings
  3. Browser Cache Settings
  4. CDN Cache Settings
  5. L2 Caching
  6. Slice Settings
  7. Advanced Cache Key

1. How it works

Edge Caching is a standard feature available for all Edge Applications at Azion, which guarantees performance and low latency.

Edge Caching consists of a reverse proxy architecture, through which your users connect to the Edge Nodes of our highly distributed global network, which can cache your content with Edge Caching and even expand its versatility with the L2 Caching add-on.

When users request content on the internet, their browser or application starts by resolving DNS to translate the requested domain to an IP address. When using Azion, you will set up the DNS for your web application to point to an address generated when creating a domain at Azion.

Azion selects, through its SDN Router, the Edge Node closest to the user, reducing latency and increasing the content transfer speed.

In this architecture, your content or web application needs to be available from an origin, which can be one or more web servers in your infrastructure, a cloud service or a Cloud Storage of your choice.


2. Cache Settings

It is the service responsible for creating Cache Settings, containing several features that expand the way the content is delivered.

There are two versions of Cache Settings:

  1. the first version focuses on static content, that is, there is no need of having the Application Acceleration service enabled;
  2. the second version, through Application Acceleration, extends several configuration options in Cache Settings interface.

To create or edit a Cache Settings configuration, proceed as follows:

  1. Access Real-Time Manager, go to Edge Computing on Products menu and select Edge Applications;
  2. Add or edit one Edge Application;
  3. Access theCache Settings tab;
  4. Edit or create a Cache Settings configuration;
  5. Click the Save button to save your settings.

3. Browser Cache Settings

The Browser Cache Settings is the amount of time that content is cached in the web browser. You can set the Edge Application to:

Honor Origin Cache Headers Override Cache Settings
This feature honors the cache definitions sent by your origin servers through HTTP headers (Cache-Control and Expires) sending the same headers to the web browser. This feature overrides the cache of your origin server by setting the TTL (Time to Live) manually.

4. CDN Cache Settings

CDN Cache Settings is the amount of time the Azion’s Edge Applications take to Cache the content. You can set the Edge Application to:

Honor Origin Cache Headers Override Cache Settings
This feature honors the cache definitions sent by your origin servers through HTTP headers (Cache-Control and Expires) sending the same headers to the web browser. This feature overrides the cache of your origin server by setting the TTL (Time to Live) manually.

5. L2 Caching

L2 Caching is an additional layer of cache between Azion Edge and your origin that helps to further reduce the load on your infrastructure.

When accessing your applications on Azion, your user accesses our highly distributed network capable of performing edge caching. By enabling L2 Caching on your edge applications, you have a second layer of cache that will be responsible for feeding the edge, keeping your content cached for as long as you specify.

L2 Caching was designed especially for objects that can be cached for a long period of time. So, you can only enable it in cache policies with time-to-live (TTL) equal to or greater than 30 days (2592000 seconds).

Whenever needed, you can use Real-Time Purge to expire your L2 Caching content before the estimated TTL time. Remember to expire first on L2 Caching and only then on Edge Caching, to avoid feeding outdated L2 content back to the edge.

The L2 Caching module works with a minimum TTL of 2592000 seconds, that means, 30 days.

You cannot use “Honor Origin” setting for CDN Cache. You must set a TTL to Override CDN Cache instead.

To use the L2 Caching module, proceed as follows:

  1. Access Real-Time Manager, go to Edge Computing on Products menu and select Edge Applications;
  2. Edit the Edge Application that you want to use the module;
  3. To enable the L2 Caching module, continue on theMain Settings tab and select the option L2 Caching in the Edge Application Modules section;
  4. After enabling the module, access the Cache Settings tab;
  5. Add or edit the Cache Settings configurations which will work with the L2 Caching layer;
  6. Set the Default TTL (seconds) **field to a value greater than or equal to **2592000 seconds;
  7. Enable the option L2 Caching;
  8. Click the Save button to save your settings.

6. Slice Settings

Slice is a feature for Edge Applications that allows large amounts of data to be processed more effectively, reducing latency and saving bandwidth.

By enabling this feature, the file or media is fragmented. These fragments are gradually delivered to the end user according to the data consumption, avoiding an abrupt data transfer that may not be finished by the user. The data is cached on demand whenever the user requests it. When the request is made, Slice begins to operate.

Once the Slice feature is enabled, the current object cache key will be ignored and a new Slice cache key will be created.

This feature works with a default slice-range of 1024kB. If you want to modify the slice-range, contact our Sales Team.

Slice is not restricted to Edge Caching module. You can also enable this feature on L2 module, which allows you to cache content, which allows you to cache content for longer, delivering it on demand to the end user, improving performance and availability.

By definition, Slice operates with the Edge Caching Layer. However, you can have an extra layer of caching by enabling the L2 Caching.

To activate the Slice Settings feature, proceed as follows:

  1. Access Real-Time Manager, go to Edge Computing on Products menu and select Edge Applications;
  2. Click on an existing Edge Application or create one;
  3. Select the Cache Settings tab and click on the determined Cache Settings list;
  4. In the Slice Settings section, enable the Slice Configuration button. By default, the Edge Caching setting will be automatically selected;
  5. Check the box in case you want to enable L2 Caching.

7. Advanced Cache Key

You can use Azion to deliver your dynamic or static content. Even the dynamic part of a website can often be cached for a user profile, grouped according to the specific needs of your application, either city, browsing profile, or shopping profile.

If you want your dynamic content to be cached on Azion’s Edge Nodes, you can define advanced cache key rules based on Cookies or Query String.

As a standard, Azion considers each URL as a different object in cache. Through the Advanced Cache Key, you can set up a custom cache key rule based on Cookies or Query String and thereby define the segmentation of your content in your application.

To enable this feature, proceed as follows:

  1. Access Real-Time Manager, go to Edge Computing on Products menu and select Edge Applications;
  2. Edit the Edge Application you want to use the module;
  3. In the tab Cache Settings, add or edit a custom cache setting;
  4. In the Advanced Cache Key section, define your custom Cache by Query String and Cache by Cookie setting.

Cache by Query String

At Azion you define how you want the content to be cached according to variations of Query String 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 distinct URLs just by varying the Query String will be considered as the same cached object, for example http://yourdomain.com/path?queryA and http://yourdomain.com/path?queryB will 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 field “city”, the URLs http://seudominio.com/path?cidade=A&nome=X and http://seudominio.com/path?cidade=A&nome=Y will be considered as a single object in cache, while URLs http://seudominio.com/path?cidade=A&nome=X and http://seudominio.com/path?cidade=B&nome=X will be considered as different objects.

Content varies by Query String, except for some fields (Blacklist): 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 field “random”, the URLs http://seudominio.com/path?cidade=A&random=123 and http://seudominio.com/path?cidade=B&random=123 will be considered different object in cache, while http://seudominio.com/path?cidade=A&random=123 and http://seudominio.com/path?cidade=A&random=456 will be considered as the same object in cache.

Content varies by all Query String fields: defines that the cache key must consider all Query String fields, that is, two different URLs by the variation of the Query String will be considered as two different cached objects, for example http://yourdomain. com/path?queryA and http://yourdomain.com/path?queryB will be stored as separate objects in the Azion cache.

To increase the efficiency of cashing, you can enable the Query String Sort feature. If enabled, all fields in the query string will be sorted, making the position of the fields irrelevant in the cache key definition. If the position of the fields is relevant to differentiate their content, you must leave this feature disabled.

Note: By default, Azion will only cache GET and HEAD requests. By checking Enable caching for POST, you will allow Azion to cache POST requests as well. Caching for POST requests implies using the request body as part of the cache key.

Cache by Cookie

You can also distinguish objects in the Azion cache by name/value of cookies.

Content does not vary by Cookies (Improves Caching): defines that cookies will not be taken into account to differentiate objects in the Azion cache. Only the URL will be considered for differentiating the objects.

Content varies by some Cookies (Whitelist): you can list the name of the cookies that your application uses to differentiate cached objects. All other cookies will be ignored. As a result, you can segment your content by user profiles and more. This is the most recommended option if you use cookies to manage user sessions.

Content varies by Cookies, with the exception of a few (Blacklist): you can list the name of the cookies you want to ignore in the definition of the cache key and, thus, all cookies will be considered, except for those listed. Content varies by all Cookies: defines that in addition to the URL, all cookies must be considered to differentiate objects in the Azion cache.

Use this feature to segment your content by user profile, browsing session, access region or according to your content targeting needs.

Adaptive Delivery

Adaptive Delivery – requires Adaptive Delivery product – detects the user’s device group and allows you to configure how Azion Content Delivery should cache your content.

Content does not vary by Device Groups (Improves Caching): choose this option if you want to deliver the same version of the content, regardless of the device detection;

Content varies by some Device Groups (Whitelist): choose this option if you want that Azion keeps device-based variations of your objects in the cache.

Click the Save button to save your settings.


Didn’t find what you were looking for? Open a support ticket.