Chapter 2. Leveraging a CDN
Browser cache is a great tool, and I would say table stakes for starting to create a frontend, scalable site. But when your traffic and performance goals demand more, it is usually time to step up to partnering with a content delivery network (CDN). This chapter we look at leveraging a CDN to both improve your performance and offload the number of requests via proxy caching at the edge, called edge caching.
The purpose of a CDN is to provide availability and performance for content served over the Internet. There are several ways that this is accomplished, from providing Global Traffic Management (GTM) services to route content to the closest or fastest data center, to providing edge serving.
Edge Caching
Edge serving is where a CDN will provide a network of geographically distributed servers that in theory will reduce time to load by moving the serving of the content closer to the end user. This is called edge serving, because the serving of the content has been pushed to the edge of the networks, and the servers that serve the content are sometimes called edge nodes.
To visualize the benefits of edge computing, picture a user who lives in Texas trying to access your content. Now you don’t yet use a CDN, and all of your content is hosted in your data center in Nevada. In order for your content to reach your user, it must travel across numerous hops, with each hop adding tens or even hundreds of milliseconds of latency.
See Figure 2-1 for a request made in Texas traversing a series of hops back and forth to a data center in Nevada.
Figure 2-1. Content hosted in a data center in Nevada served to an end user in Texas traversing seven theoretical hops
Now say you are leveraging a CDN that has edge nodes across the country. Your origin servers are still your data center, but mirrors of your content are stored on your CDN partner’s hundreds or thousands of edge nodes, and there is an edge node in the same area as your end user. You have eliminated all of the hops and any latency that they would bring. Even if you think of the packets as light traveling down fiber optics, if light has less distance to travel, it will reach the end user faster.
See Figure 2-2 for this same request served from the edge.
Figure 2-2. Content served from an edge node in Texas served to the same end user in Texas
Now that your content is served at the edge, make sure your cache rules for your content are set correctly, using the Cache-Control and ETag headers that we discussed in Chapter 1. Suddenly you have edge caching. Note that in addition to honoring your origin cache settings, your CDN may apply default cache settings for you. When you combine the benefits of both GTM and edge caching, you drastically increase your potential uptime.
Quantifying the Theory
I leverage edge caching for most of the sites that I run, so I thought it would be fun to quantify this theory with real, live content. To do this, I opened my command line and ran ping against a subset of content on each of my tiers: my data center origins, my origins utilizing just GTM, and finally my content served from the CDN edge cache.
What I found is that over the course of many tests, serving content via a CDN was 45% faster compared to serving it from the data center directly. Even better, there was a 67% performance improvement when serving content from our CDN’s edge cache versus serving content directly from our data center origins. See the data from my experiments in Figure 2-3.
Figure 2-3. Bar chart comparing response times for the same piece of content served from a data center origin server, from behind a CDN Global Traffic Manager, and from a proxy cache at the edge
CDN Offload
Besides speeding up delivery of the content to the end user, another big benefit of using a CDN’s edge cache is offloading traffic. Sometimes called CDN Cache Hit Ratio, this is the amount of traffic, both total bandwidth and sheer number of transactions, that can be handled by the cache nodes versus the number that gets passed back to your origin servers.
The ratio is calculated by dividing the total number of requests that are reported by the CDN by the total number of offloaded or cached responses over a time period, so:
CDN offload = (offloaded responses / total requests)
Think about it this way: say you get in 25,920,000 requests per day, and your CDN offload is 95%. This means that the CDN would absorb 23,328,000 requests, and your origins would only need to handle 2,592,000 requests. In other words, you’re going from 300 requests per second down to only 30 requests per second, thereby drastically reducing the amount of infrastructure you would need at your origin.
Summary
Content delivery networks are great tools and an integral part of your client-side scaling strategy. By leveraging proxy caching on an edge network, we can serve content faster to our end users and have a more efficient infrastructure because the CDN is absoring a percentage of the incoming requests.