Skip to content

CDN Purge Speed Stats

Updated hourly.

How long does it take to purge a single cached object on Amazon CloudFront, CacheFly, Edgio and Gcore?
CDN Planet measures CDN Purge Speed every hour from 3 global locations. Learn more.

Last 7 Days (dummy data)

Purge Time in seconds based on 504 measurements from all locationsTime between receiving the response of the purge request to the CDN API and sending the request to the CDN that returned a cache MISS

p25 Median p90 p99
CacheFly 0 1 2 3
Gcore 0 4 5 6
Amazon CloudFront 0 8 12 13
Edgio 0 11 22 33

Last 30 days (dummy data)

Purge Time in seconds based on 2160 measurements from all locationsTime between sending the purge request to the CDN API and sending the request to the CDN that returned a cache MISS

p25 Median p90 p99
CacheFly 0 1 2 3
Gcore 0 4 5 6
Amazon CloudFront 0 8 12 13
Edgio 0 11 22 33

FAQ

What is CDN Purge Speed Stats?

CDN Purge Speed Stats is accurate data about how fast you can purge a single file on various content delivery networks, based on hourly measurements from 3 global locations (United States, United Kingdom and Hong Kong).

What is the definition of Purge Time?

Purge Time is the time between sending the purge request to the CDN API and sending the request to the CDN that returned a cache MISS. More details are in the next FAQ item.

How is the data collected for CDN Purge Speed Stats?

The main application runs in the United States and there is a worker application in 3 global locations: United States, United Kingdom and Hong Kong. These applications live on the Fly.io network.

Every hour, for each CDN, the main app takes the following steps:

  1. Instruct the worker apps to prime the CDN cache (= get the test object into the CDN cache); log the CDN POP/server that served the cache HIT response
  2. Send a single file purge request to the CDN API; log the time of sending the purge request as the PurgeStartTime
  3. For each location, instruct the worker apps to send requests to the CDN for the test object until cache MISS (= CDN serves the object after a fresh origin pull, as observed from A) the CDN response header(s) that signify the cache status (HIT/MISS/...) and B) the x-cdnp-time response header the origin serves to CDN and CDN sends through to client which has the timestamp of when origin served the response to CDN; log the time the worker sent the last request to CDN as the PurgeEndTime
  4. Calculate the Purge Time for each location from the delta of the location's PurgeEndTime and the PurgeStartTime, rounded to a zero-decimal number in seconds

From a user's perspective, a purge starts when submitting the purge request and so the PurgeStartTime is when the main app sends the request to the CDN's API. After purge, for each location, the main app instructs the worker app to send a request to the CDN until a cache MISS from CDN is observed. The PurgeEndTime for the location is set to right before sending that last request from main app to worker app because the round-trip time between main app and origin (via worker and CDN) should not be part of the measured Purge Time.

The worker apps send requests to the CDN in phase 3 (until cache MISS) per the following schedule:

  • Immediately, so it's possible to measure a Purge Time of 0 seconds
  • Every 1 second the next 5 seconds
  • Every 2 seconds the next 10 seconds
  • Every 5 seconds the next 45 seconds

The schedule has exponential backoff because it is efficient and when evaluating and comparing Purge Time of CDNs, a median value of e.g. 25 seconds provides the same insight as a median value of 26 or 27 seconds. In our opinion, it's fine for the precision to decrease as Purge Time increases.

If the worker app has not observed a cache-MISS within 60 seconds after purge, the CDN Purge Time is set to 65 seconds.

We selected US, UK and HK as locations for the worker apps primarily because we want to measure Purge Time from different continents. Another benefit is that all major CDNs have POPs here and our origin lives in these locations too, so the probability of worker <-> CDN requests and CDN <-> origin requests timing out is very low.

The main <-> worker and worker <-> CDN connections are persistent to reduce the impact of network latency on measured purge time. More specific: the worker <-> CDN connection that is created during the priming phase is re-used during phase 3.

Why measure purge time from multiple locations?

Measuring from multiple locations provides insight into how fast purging happens globally and may show interesting geographical differences.

Can I see stats for a single location?

Yes, the page with purge speed details for a CDN show purge speed by location. Click the CDN name in the top table on this page.

What do p25, median, p90 and p99 mean?

These are all percentiles. In p25, the 25 signifies it is the 25th percentile. The median is a word for the 50th percentile.

Numerical data can be sorted in increasing or decreasing order. Thus the values of a numerical data set have a rank order. A percentile is the value at a particular rank. Source: Computational and Inferential Thinking

To calculate the percentiles for Purge Time, we order all values (from all locations) in increasing order and get the 4 percentiles we want. A p25 of 12 tells you 25% of the purges took 12 seconds or less to finish and 75% of the purges took longer than 12 seconds to finish.

Will more CDNs be added to CDN Purge Speed Stats?

Yes, we expect to add several CDNs in the coming weeks/months.

How can I contact you, to give feedback or learn more?

Reach out on Twitter or send an email to info@cdnplanet.com. We'd love to hear from you!