To better understand the integration between both technologies, let’s have first a quick overview on what is Akamai.
WHAT IS AKAMAI?
Akamai is a CDN (Content Delivery Network) that has servers all over the world, delivering the content of a website and caching that part of the content that doesn’t need to be constantly updated.
Beyond AEM, as CDN, among Akamai’s pros we can find some remarkable points:
- Faster delivering content: Is not the same that an user access to the website servers than could access to Akamai. In Akamai the content is available in closer servers and cached.
- Better balancing of the content: apply an Internet-centric approach to global load balancing and real-time fail-over. Designed to ensure high availability and responsiveness to user requests.
- Safety: put another wall between the user and your website.
- Improve user experience: Due to previous points the user has a better experience when requests content.
We can find more information about AEM dispatcher on this previous post
INTEGRATION WITH AEM
Currently, there are no tools that helps on the integration of Akamai & AEM. Akamai can be customized, so it also depends on how you implement your website.
There are a few options that can be used to integrate Akamai with AEM (it doesn’t mean that there are others):
A first option is to let Akamai decide what is and what isn’t cached based on URL rules (that you can configure). In this model you point the DNS for your website to Akamai and it decides if the request is subject to caching or not. Requests not subject to caching then pass through to your systems (AEM dispatchers will take care if should handle own caching or serve from publish instance).
But most of the clients uses a TTL approach to flushing Akamai cache rather than trying to invalidate it because the benefits aren’t worth costs ,especially if you’re using dispatcher.
The TTL (Time To Live) tells the CDN server, in this case Akamai, how long to wait before checking for a changed/updated version of the file, and tells a web browser how long it should keep a file locally cached on the computer before requesting the file again. Generally, all pages from a site has the same TTL, let’s say 10 minutes, but in every site it can be configured some paths exclude from cache or a different TTL.
For example, pages that are constantly updated, will have a lower TTL (less than 10 minutes) but pages that are only updated once a day or a week, can have a higher TTL (3 hours for example).
So the way on how it works will be:
- A page is activated on AEM.
- AEM dispatcher invalidate the cache for this document.
- After reach TTL again, the page is invalidated on Akamai servers.
It is hard to find the best approach to integrate AEM & Akamai, because Akamai works with “time” and AEM with manual invalidation of the content. This means that, for example, when a page is activated, it is invalidated on dispatcher as well. But on Akamai remains the older version of the page till the TTL finish again.
Disptacher configuration is also involved, because a page invalidation can invalidate more content due to the statfile (we will talk about this on other posts 😉 ). This “extra” content invalidated on dispatcher won’t be invalidated on Akamai and it would be needed to clean the cache of this content manually or using an API.
Keep working on find a way to handle it…
This is an image that represents the integration of AEM & Akamai:
PROS, CONS AND TAKE IN ACCOUNT
Some of the benefits of having Akamai working with AEM: beyond all pros that a CDN can give us, AEM will be less stressed and Publish instances/dispatchers will work less and have more stability.
On the other hand the users will have a possible delay on view on new contents and possible mis-alignments between Akamai servers due to TTL (Higher is the TTL and higher is the possibility to have misalignments on servers).
Some points to take also in account:
- Akamai cache also query string parameters → useful for search pages with query string (use a low TTL)
- Statlevel → When a page is invalidated, other pages are invalidated on dispatcher as well but not on Akamai. Two options to see the invalidation on Akamai: wait for TTL, invalidate manually or through an API.
DO YOU REALLY NEED AKAMAI?
Unless you have a lot of money and want to waste it, the thing really depends on the traffic of your website.
Use a CDN for a website that will be focused only on local target, let’s say just a country, is kind of useless. On the other hand if the website expects to hold a crowd over the world could be a good idea, improving speed, traffic, safety and user-experience.
AUTHORS
Francesco Crispiatico, Jonas Magdaleno, Marco Pasini
Great article!!
How does one invalidate an asset cached on akamai ( a pdf which would have changed)? Akamai offers api it seems but is that the way generally followed?
Hi, as explained in the post, the standard approach on Akamai is based on TTL, hence a time measure.
This means that if some contents changes frequently, I will set up a lower TTL and if they are quite static an higher TTL.
Obviously, there can be the need for a more precise and real time approach. Akamai offers some API, you can look up the documentation here https://api.ccu.akamai.com/ccu/v2/docs/ . In these cases it is possible to create an ad-hoc invalidation process for the pages/assets involved but it is not an immediate setup.
Basically, it is a matter of understanding when TTL does not meet our required caching standards.