Content Delivery Networks are systems designed to increase the capacity of your website. But is it worth implementing? How much does it improve scalability? 10%? 20%? 100%? Would you believe over 300%? How about that it alone quadrupled the amount of throughput our website can handle?
Before we delve into the details of the results, we first need to explain what a Content Delivery Network is and how it works, so we can understand why these improvements were so dramatic.
How it works
A Content Delivery Network (CDN) is a system of distributed servers that takes advantage of server placement, caching, and DNS to deliver content quickly and efficiently. Rather than distributing all information from your main server (called the “origin server”), it uses a series of proxy caches (called “edge servers”) to get certain content to your users faster.
Put simply, CDNs work like this:
- A user makes a request for a piece of content (e.g. photo.jpg). DNS directs the request to the nearest edge server.
- If the edge server doesn’t have that content in its cache, or the content it does have is expired, the edge server makes a request to the origin server for the content.
- The origin server returns the content to the edge server. The edge server then caches this fresh content.
- Finally, the content is delivered to the end user from the edge server.
On subsequent requests for the same content, the process goes a little differently:
- A user makes a request for a piece of content (e.g. photo.jpg). DNS directs the request to the nearest edge server.
- The edge server has the content cached, so it delivers that content to the end user directly. No requests are made to the origin server.
This happens for ANY user that gets directed to this edge server. When one user makes the request, all subsequent users in that area will be drawing from the content that’s stored in the edge server cache. In this way, CDNs work like browser caches, but they are shared between multiple users.
This type of caching works best on “static content” or content that isn’t going to change very much. Content that is constantly expiring or changing won’t be stored in the edge server for very long, meaning it gives no benefit from being cached like this. Things like pictures, CSS documents, media files, and JavaScript files are all good candidates for CDN storage. HTML pages, on the other hand, are typically handled directly by the origin server because they must be dynamically built by the web application for each user.
As you can see, most requests are now being handled by the CDN, freeing up valuable resources within the origin server. As a result, the origin server can handle a greater number of users since each user is making significantly fewer requests to it.
You can read more about how CDNs work here.
How to Implement
Originally we were going to compare the efficiency of a bunch of CDNs paired with our website. This turned out to be a project for another time since applying a CDN to our website messes with DNS and that’s something we didn’t want to have to deal with. In the end, we only ended up testing one: Amazon Cloudfront. This was the one that made the most sense anyway, since LoadStorm is hosted through AWS and would therefore be the easiest to set up.
For a detailed look at how to set up a Cloudfront CDN and integrate it into WordPress using W3TC, click here.
Results
Overall, load time did not significantly decrease by attaching a CDN, only dropping by about 4.6%. However, increasing page speed isn’t exactly the function of a CDN. To truly see the impact the CDN has on our website, we must perform a load test!
In addition to the benchmarking tests we performed with WebPageTest, we also performed some initial benchmarking tests with LoadStorm, testing our website up to 5000 concurrent users.
At the time of benchmarking, we received our first timeout error at around 1,600 users. Not too bad, but we can do better.
Now let’s run the exact same test after enabling a CDN and see how well the website does.
Not a single error, and we reached 5,000 users with no complications. Since the CDN is now handling the bulk of the content requests, this takes a massive load off of the main servers. Five thousand is easily high enough to handle the amount of traffic LoadStorm’s website gets, and we could probably stop there if we wanted to…but let’s keep going.
Next, we’ll hammer it again with LoadStorm, this time going up to 25,000 users!
Unfortunately, we had to cut this one short. Due to some complications involving the LoadStorm website’s database being located on the same server as the LoadStorm application’s database, we accidentally came pretty close to crashing them both. Nevertheless, we found our breaking point: 7628 concurrent users. So the number of concurrent users we could handle before getting timeouts increased by 376%.
That’s to say nothing of what the CDN did to our maximum throughput and peak requests per second! Throughput peaked at 53,455 kB/s, which is over four times the benchmark’s value of 12,730 kB/s. Requests per second similarly quadrupled, going from 537 requests/s to 2,250 requests/s. All from making a single change. All from setting up a CDN.
Bottom Line
If you’re looking for an easy way to improve the scalability of your website, setting up a CDN is really the first thing you should do. It’s an quick way to dramatically increase the number of users your website can handle. This works by passing off most of the workload to the CDN, so most requests can be handled outside of the main server, freeing up resources to handle more users. Curious about how big an impact a CDN has or could have on your website? Try LoadStorm for free today and find out!