← back to TurboBytes blog

How we engage with our customers

Published on Thu, May 24, 2012 by Aaron

We like to interact with our customers, to understand their business goals and their needs and requirements for content delivery. Our primary KPI is customer satisfaction and we will 'do what it takes' to provide a great service and have happy customers. During the trial period and initial implementation we often discuss performance data and CDN behaviour in great detail, as our customers want to be convinced of two things:

  1. CDN content delivery is fast & reliable
  2. Interaction between origin server and CDN is fast and efficient
On May 10, our customer Wordans, a Canada based webshop for custom t-shirts with a global audience, started a conversation with us about GZIP compression, after seeing our CDN (Internap) showing undesired GZIP compression behaviour. We were able to quickly find out what was going on and Wordans make improvements on their origin servers, to reach optimal CDN performance.

The conversation with Wordans

Wordans CTO Anthony Alberto sent the first message at 3:38 PM local time (Montreal, Canada), which is 3:38 AM for Sajal Kayan, TurboBytes CTO, operating out of Bangkok, Thailand.

IP addresses, host names and file paths have been masked at Wordans’ request.

Anthony
Hello

Another thing to look into tomorrow :
Looks like gzip compression is disabled on the CDN ?
Quick test here :
http://cdn.domain.com/file?nocache => Downloads 600KB+
http://nocdn.domain.com/file?nocache => Downloads 112KB

I'm serving the files gzipped, therefore I'd expect that even if the cdn node doesnt gzip content, at least it doesnt unzip it before sending it to the client !
Sajal (4 minutes later)
Hi Anthony,

Your origin does not set "Vary: Accept-Encoding" response header.

That will break gzip. Without that header, the CDN (and any upstream proxy) will keep only one version of the object in cache.

Are you unsetting the Vary header in your Varnish?
Anthony (71 minutes later):
Hmmm ... will have to check since each request goes through 2 nginx and 1 varnish ...
Will fix it tomorrow, thanks
Sajal (4 minutes later)
I did some tests after sending the previous mail... 
It seems if Vary header is missing then Internap will ungzip it. Probably to prevent from sending gzip to incompatible clients.
Anthony (2 minutes later):
Yeah must be a standard reverse proxy behaviour.
I have a Squid instance in France and it's doing the same thing, sending unzipped content
Sajal (2 minutes later)
Internap uses squid.... I think a little modified/patched
Anthony (7 minutes later):
Hello,
So i was missing an option in my nginx config to enable the Vary encoding header.
I enabled it, now the response header is there but ... it's still unzipped when it goes through the CDN :(
Sajal (5 minutes later)
I'll look into this tomorrow... Can you check your origins access log for the response size when CDN requests from origin? Is it being served gzip ?
Anthony (5 minutes later):
First log is when I hit it directly, second is through the cdn

xx.xx.xx.xxx - - [10/May/2012:19:17:15 -0400] "GET /path/to/file/file.ext?cache=18778 HTTP/1.1" 200 114647 "-" "Mozilla/5.0 (Windows NT 6.1; WOW64) AppleWebKit/535.19 (KHTML, like Gecko) Chrome/18.0.1025.168 Safari/535.19"

xx.xx.xx.xxx - - [10/May/2012:19:07:07 -0400] "GET /path/to/file/file.ext?cache=18778 HTTP/1.1" 200 660877 "-" "Mozilla/5.0 (Windows NT 6.1; WOW64) AppleWebKit/535.19 (KHTML, like Gecko) Chrome/18.0.1025.168 Safari/535.19"

So it looks like Squid asks only for the plain text version! That sucks, I guess I can't do anything about this on my end?
Sajal (3 minutes later)
This is unusual. Ill look into it tomorrow. We have customers on Internap and gzip works as expected...
Can you also log the accept-encoding request header to be sure?
Anthony (21 minutes later):
Weird, it asks for the gzip version too :

With CDN :
xx.xx.xx.xxx - - [10/May/2012:19:39:54 -0400]  "GET /path/to/file/file.ext?test231=18778111 HTTP/1.1" 200 660877 "-" "Mozilla/5.0 (Windows NT 6.1; WOW64) AppleWebKit/535.19 (KHTML, like Gecko) Chrome/18.0.1025.168 Safari/535.19" "gzip,deflate,sdch"

Without CDN :
xx.xx.xx.xxx - - [10/May/2012:19:41:19 -0400]  "GET /path/to/file/file.ext?test232=tesfwfewf HTTP/1.1" 200 114647 "-" "Mozilla/5.0 (Windows NT 6.1; WOW64) AppleWebKit/535.19 (KHTML, like Gecko) Chrome/18.0.1025.168 Safari/535.19" "gzip,deflate,sdch"

There must be something more to it ... well, I'll try to find out more tomorrow!
Anthony (4 minutes later):
Forget it, I fixed it ...

For whatever reason, nginx refuses to serve gzipped content to any proxy unless you set a particular option :gzip_proxied ...

Sorry about that!

Anthony and Sajal were able to efficiently resolve the GZIP problem together. The quick, knowledgeable reponses from Sajal helped TurboBytes win Wordans' business. We are happy to have you Anthony, thanks again for choosing TurboBytes!

Comments