Without tooling, debugging multiple CDNs at the same time is a complicated and time-consuming affair. At Warpcache, debugging our multi-CDN solution is a necessary evil at times, and to make things easier we’ve built a tool to smoothen the process. Read more below about our debugging challenges, and what’s important to look out for.
In this post we introduce our debugging tool and demonstrate an example with gzip compression.
Multi-CDN Debug Tool
What makes debugging multiple CDNs tricky, is that a bunch of different variables need to be compared at the same time. You’ll want to execute the same request to a number of CNAMEs, and show them in a simple overview for easy comparing.
Besides the overview our debug tool has a few additional features:
- It fetches the headers from all CDNs in the multi-CDN ‘mix’ and the headers from the origin
- It doesn’t use caching (but who’d ever debug CDN’s with their browser- right?)
- It can give you
curlcalls so you can test responses yourself
- Simple interface:
- Selection boxes of your vhosts and aliases
- Tick boxes to toggle your CDN display settings
- Columns per CDN for easy header comparison
- Direct filtering on headers
- Fetch anything from your property (
POSTrequest methods are possible)
- Big comparison table
Here’s what our debug tool looks like in the Warpcache Control Panel:
Debugging gzip compression
Compression is important in content delivery and most CDNs support gzip compression in one form or another. An issue that our debug tool had found out was that different CDNs apply different gzip compression and rules, which can be confusing.
Take a look at the following image:
You see a 4 tiered multi CDN setup. One origin, and 4 CDN providers. The debugger fetched the same file on all CDNs and the Origin at the same time.
Furthermore you can see:
- The Origin sends an uncompressed file – no Content-Encoding header
- HighWinds compresses the file with gzip
- MaxCDN doesn’t compress the file
- Hibernia compresses the file with gzip
- Akamai doesn’t compress the file
In this scenario some end-user users are receiving larger files. This is bad! Bigger isn’t always better, and the larger the files are the longer end-users will have to wait for the content to load. On top of that, a bigger file-size means higher traffic usage: more Gigabytes are sent over the CDNs, and you’ll be charged for them at the end of the month. A sub-optimal situation for the end-user, and for you.
We’ve found that not every CDN treats gzip compression in the same way. They use different compression levels. Additionally when debugging multiple CDNs, we recommend checking that your CDN doesn’t compress already gzipped files.
To conclude, we can state that setting up gzip compression isn’t straight forward.
It’s good practise to validate your CDNs gzip compression configuration. It might just be you’re serving out larger files than you’re aware of.