What does it look like to turn off 100,000+ CDN PoPs?

Is this going to hurt the performance of your website?

This is a common question asked across the industry, We have previously covered this topic around the power of PoPs (Points of Presence), Are lots of PoPs better? Or are smaller numbers of “Super” PoPs better? https://www.section.io/2014/09/23/how-many-pops-does-it-take-to-cache-a-website.html

In a followup we have looked at an actual customer turning off a CDN that comprises 100,000+ PoPs (216,000+ servers globally).

Solution overview:

Having been unable to achieve an appropriate HTML caching strategy with their existing CDN provider, Section were engaged to sit behind the current CDN provider so that the customer in question could leverage the Section toolset (Development workflows, Instantly available logs and detailed metrics) so that HTML content could be cached and traffic offloaded from origin servers.

The implementation methodology above was chosen to be able to validate, firstly that HTML caching could be easily implemented with the Section platform and secondly to provide a safety net against the boogie man of “less than 100,000 POPs may result in worse performance”.

Having successfully implemented HTML caching the next step was to turn off the 100,000 PoPs that were caching static content. This was the moment of truth for a specific example of switching from running on 100,000 PoPs globally to another CDN (Section) that has global reach but does not sell PoP count as its core feature.

Results:

Suspense over in the graph below we measure actual website speed via the New Relic Browser module. This is a RUM based performance monitoring tool that measures the page load performance of every single user and combines this into an overall metric.

As you can see below, There was a slight performance improvement in network time and day on day trends. 100,000+ PoPs have been removed and performance has actually improved!

Overall page performance:

Day on Day performance showing a slight improvement in response times:

Network time - This is the time taken for items to be downloaded (as opposed to time taken to generate content on server or process in browser):

Additional details:

As we had visibility of incoming connections from the legacy CDN we could see that the actual number of PoPs that were serving user content (and connecting back to origin servers when caches were missed) was far far less than 100,000. The actual number of POPs that were serving any volume of traffic was < 10.

This makes sense considering that cached items are not shared between PoPs. If you had the same image or javascript file being requested via each PoP in turn you would have to make 100,000 requests for the same piece of content before you hit from cache.

Summary:

Hopefully this helps resolve the hype around very large CDN PoPs numbers, There may even be a web performance anti-pattern around having large numbers of PoPs. Either way we feel that what you cache (HTML in addition to static content) is far more important than thousands or millions of PoPs.