Debugging multiple CDNs

Debugging multiple CDNs

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 curl calls 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 (GET, HEAD and POST request methods are possible)
  • Big comparison table

Here’s what our debug tool looks like in the Warpcache Control Panel:

Multicdn debugger

Warpcache debug overview

 

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:

debugging gzip per cdn

Different gzip compression levels per CDN

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.

About the Author

Thijs de Zoete

Technical guy at Warpcache