Blog

Using CDN Server Timing to Monitor CDN and Origin Performance

November 16, 2018 · by Tim Vereecke ·

Akamai mPulse combined with an Akamai content delivery network (CDN) gives you a powerful way to monitor the performance of your CDN and your origin.

The secret to this new capability is server timing. Here’s how it all works:

When mPulse is injected via Property Manager, Akamai adds extra server-timing response headers. These headers follow the Server Timing API and can be consumed out of the box via mPulse. New mPulse timers are available for the base page as well as all resources (CSS, JS, fonts, images, etc.)

Below is a helpful diagram that visually explains the difference between CDN Edge Time, Origin Time and Round-Trip Time and how they relate to the standard mPulse Back-End Time:

main chart

There’s an in-depth description of mPulse system timers here, but let me just give you a couple of quick definitions for the items you see in the diagram above:

  • Round-Trip Time: This is the round-trip time between the browser and the Akamai edge server (nearest to the end user). This timer can help quantify how well connected your end users are to the nearest Akamai point of presence (PoP).
  • CDN Edge Time: This is the time between when the first byte of the request is received by the Akamai edge server from the client browser, and just before the first byte of the response is written back. This does not include the time that may or may not have been spent forwarding the request to the origin. It applies to requests delivered by the Akamai network via an mPulse-enabled property configuration. This timer can help quantify the time spent within the Akamai CDN.
  • Origin Time: This is the round-trip time between the Akamai edge server (nearest to the origin) and the origin. This includes the time the origin spends handling the request. Note that this time is only relevant when content is served from the origin, and not from the CDN cache. It applies to requests delivered by the Akamai network via an mPulse-enabled property configuration. This timer can help diagnose whether the origin is the source of slow load times.

Example Headers

Now, you may be asking, which headers do you see for dynamic requests and how do they look when content is served from cache? Let’s take a look at a couple of examples.

1. Dynamic request/cache miss example: Dynamic requests traverse the full Akamai network all the way to the origin. In these cases, you would see these headers:

headers

2. Cache hit example: When there is a cache hit (i.e., content is served by an edge server), the request will *not* go all the way back to the origin, as shown in the diagram below.

chart

In the cache hit scenario, you would see these headers:

headers2

Here, the origin time is not present. The cdn-cache is marked as HIT and the edge duration will be smaller as well.

Consuming This Data

All the existing mPulse dashboards and widgets can be filtered to zoom in on this data, and the waterfall dashboard was also improved: hovering over a resource in the waterfall diagram of mPulse shows these new timers on the base page and all individual resources:

dashboards

It’s not just mPulse which can consume this data; you can also use these headers to debug in Google Chrome DevTools and WebPagetest.

webpagetest

On the left, you can see Chrome DevTools exposing the server timing headers; on the right, a screenshot of the response headers in WebPagetest.

Further reading

If you’d like to go a bit deeper into this topic, I recommend you check out this full overview of server timing by my Akamai colleague Charles Vazac: “Using Server-Timing for App and CDN Monitoring”.

Tim Vereecke is a web performance architect at Akamai Technologies.