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:
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.
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 !
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?
Hmmm ... will have to check since each request goes through 2 nginx and 1 varnish ... Will fix it tomorrow, thanks
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.
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
Internap uses squid.... I think a little modified/patched
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 :(
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 ?
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?
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?
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!
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!