Tips for caching with the Akamai CDN – Acquia Support Knowledge Base

Issue

I'd like to better understand Akamai CDN caching.

Resolution

The following are several tips and tricks that will help the Akamai content delivery network (CDN) work well with Drupal in Acquia Cloud.

Turn off Cache Purge Logging for the Drupal 8 Module.

as outlined in https://www.drupal.org/project/akamai/issues/3001392 The Akamai module for Drupal 8 stores the Purge status in a key_value pair. On a busy site with many content updates, this can create performance problems as keeping track of a large amount of data in a single table row is poor design.

If you need to have the Akamai module installed, then from the purge settings, /admin/config/akamai/config set the Purge Status expiry to 0

Using an edit domain with Akamai

Some of our customers using Akamai may want to set up edit domains for their authenticated users. Acquia recommends you discuss with Akamai whether doing so is appropriate for your website's needs.

Purging items from Akamai

You can download and install the Akamai module to help you purge items from the Akamai cache. This module lets you purge content programmatically, as well. For example:

// Tell Akamai to purge $params = array(   'action' =&gt; 'remove',   'domain' =&gt; 'production',   'email' =&gt; $email_to_notify_when_purged, ); $akamai = akamai_get_class($params); foreach ($file_paths as $filepath) {   $path = str_replace($base_file_path, '', $filepath);   $path = ltrim($path, '/');   $response = $akamai-&gt;clear_url(array($path));   $response['client'] = $akamai;   drush_print("Submitted Akamai purge request: $path", 4); }

Working with Akamai headers

If your website is experiencing performance issues, you can troubleshoot these issues by examining the response headers Akamai sends to your browser. Response headers are what HTTP servers send your browser to show you how content is being returned and how it should be handled. These headers return a lot of debugging information about the Akamai configuration and the state of the response.

By default, Akamai removes some headers. The following cURL command adds Akamai's header requests to the outgoing request, so that it will display them instead of deleting them:

curl -I -H "Pragma: akamai-x-cache-on, akamai-x-cache-remote-on, akamai-x-check-cacheable, akamai-x-get-cache-key, akamai-x-get-extracted-values, akamai-x-get-nonces, akamai-x-get-ssl-client-session-id, akamai-x-get-true-cache-key, akamai-x-serial-no" http://www.website.com/style.css

X-Cache headers

You can look at the X-Cache header to determine whether a webpage is being served from a cache, and if so, what cache is serving it. By default, Akamai prevents the X-Cache header from being sent to the browser client. To enable this header to be shown, run this Pragma directive from the command line:
```
curl -sIXGET -H "Pragma: akamai-x-cache-on" http://www.domain.com | grep "X-Cache"
```
```
X-Cache: TCP_HIT from a204-2-196-181.deploy.akamaitechnologies.com (AkamaiGHost/6.9.5-10056421) (-)
```

X-Cache responses

Here is a list of X-Cache responses you might see in your webpages' headers, and what they mean:

TCP_HIT - The object was fresh in the cache, and it came from the disk cache.

TCP_MISS -The object was not in the cache; the server fetched the object from the origin.

TCP_REFRESH_HIT - The object was stale in cache, meaning that it contained possibly outdated information, and we successfully refreshed it with the origin on an If-Modified-Since request. (An If-Modified-Since request checks to see if a webpage has changed since the last time it was cached; if so, the webpage is obtained from the origin. If not, the cached version is served.)

TCP_REFRESH_MISS - The object was stale in the cache, and refresh obtained a new object from the origin in response to the If-Modified-Since request.

TCP_REFRESH_FAIL_HIT - The object was stale in the cache, and the server failed on refresh (it couldn't reach the origin), so it served the stale object.

TCP_IMS_HIT - There was an If-Modified-Since request from the client; the object was fresh in cache, and it was served.

TCP_NEGATIVE_HIT - The object previously returned a "not found" (or any other negatively cacheable response), and that cached response was a hit for this new request.

TCP_MEM_HIT - The object was on disk and in the memory cache. The server served it without needing to contact the disk.

TCP_DENIED - The server denied access to the client.

TCP_COOKIE_DENY - The server denied access on cookie authentication.

If you want to find out the Akamai cache lifetime for a particular object, you can use the command akamai-x-get-cache-key. Akamai has an internal cache key for each webpage or object on the Akamai server. A cache key is a unique identifier that is associated with the value you put into the cache. You can use the same identifier to retrieve the value. The cache key contains the object's cache lifetime (in this example, it is set to one hour), and may also contain:
- The Akamai CP code (content provider code — an ID assigned by Akamai to a customer’s application or website)
- The origin server and URI
- Cookies or client information (device type, etc.) that may be used to cache specific versions of the response
Use this cURL command to find Akamai's internal cache key:
```
curl -sIXGET -H "Pragma: akamai-x-get-cache-key" http://www.domain.com | grep "X-Cache-Key"
```
```
X-Cache-Key: /L/5642/158025/1h/www-origin.domain.com/
```
Ideally, Akamai should be caching and serving as much traffic as possible, to maximize your website's performance and minimize the load on your own servers. You can use this cURL command to see if Akamai believes a particular request is cacheable:
```
curl -sIXGET -H "Pragma: akamai-x-cache-on" http://www.domain.com | grep "X-Check-Cacheable"
```
```
X-Check-Cacheable: YES
```

Using SureRoute to test your website with Akamai

Akamai's SureRoute technology helps speed up your website's performance by ensuring non-cacheable content is fetched using the fastest possible route between Akamai's servers. To use this service, you need to put a SureRoute test object on your origin server. SureRoute fetches this test object from the origin using various different routes. These fetches of the test object are called races. When a real request comes in, SureRoute consults its latest race data and picks the fastest path from the edge server to the origin.

Here is an example request for a SureRoute test:

63.218.71.188 - - [30/Oct/2012:21:00:04 +0000] "GET /akamai/sureroute-test-object.html HTTP/1.1" 200 4327 "-" "Akamai-SureRoute-UA" http_host=www.example.com affinity="-" upstream_addr="10.100.137.73:80" hosting_site=example request_time=0.000 forwarded_for="127.0.0.1, 204.2.243.145" upstream_status="200"

SureRoute tests run under the following conditions:

When and if the hostname is using CNAME to point to Akamai.
When the website receives traffic — and the test will only run on the parts of the website that received traffic.

If the preceding conditions are met, for each individual machine and unique SureRoute stat key, the test will run:

At least once every 300 seconds (this is the default setting).
On every 40 requests to the origin.
No more than once every 30 seconds. (This overrides the second bullet point.)

Solving intermittent redirect loops with Akamai

Akamai cache keys are case insensitive. This can cause a redirect loop to itself for the duration of the cache lifetime if subsequent requests to the URL contain changes in case.

Example: A site visitor requests www.yourdomain.com/OurMission where two letters are capitalized. The edge server does not have this object in cache and forwards the request to the origin server. The origin server sends a 301 redirect to the existing cached object (www.yourdomain.com/ourmission ). These two URLs have the same cache key, and the 301 redirect is what is cached for 1 hour on the edge server. Any request for that URL will get a 301 redirect to itself (loop) for the duration of the TTL. To test this, submit a purge for one of the URLs, and make a request for the same URL with at least one upper case character.

Solution: In the Luna control panel for the domain in question, disable the “Ignore Case in Cache Key” setting. By default it is set to "enabled".

Additional Akamai resources

For several other key points and settings you should know about, see Configuring your Acquia Cloud sites to use Akamai. For more general information on content delivery networks and other providers, see Using a Content Delivery Network with Acquia Cloud.

Acquia Products

Acquia Cloud

Topics

Drupal Projects

akamai

External Links