Comment by randomstring | Hacker News Reader

Comment by randomstring | Hacker News Reader

Amazon Cloudfront does support gzip, just not dynamically. So it requires uploading two versions of every CDN file, one uncompressed and a second that is compressed, being careful to set content-encoging and content-type headers correctly. Then all the pages on your site (assuming they're all dynamically generated of course) need decide whether the client can handle gzip or not and the link to the appropriate gzip/non-gzip version in the Amazon CDN.

The real "fun" begins when you have CSS or javascript files that reference other files in the CDN. You have to fix them to link to the correct gzip/non-gzip version of the files.

With some perl, trial-and-error it can be made to work. There are some Amazon S3 modules in CPAN, which is a big help.

The big win for Amazon CDN is the low cost to experiment: Pay as you go. Our bill for the first 3 months of playing around with S3 and the CDN (this is just for internal testing mind you) was less than a dollar. Looking at SimpleCDN, they want a minimum of $500 for a month of service before you can even access the full dashboard.

All the other CDNs I've looked at require a phone call to a sales and marketing droid to setup an account. When all I really want is a trial account and some API docs.

Amazon cloudfront supports serving gzipped files, it does not support reading the incoming request to see if it accepts gzipped files. If you read the first part of the original article, it explains why that doesn't work. It only works when you dynamically generate the page on EVERY request, which makes caching impossible. Hence, it's never been a viable option for us, which is what lead to this article.

No, I understand. I implemented the first suggested "fix" in your article that you say "won't work."

You seem to think caching two copies of a file is unreasonable (it all depends on how big your site is I guess), but in our case all pages are dynamic and uncachable so this requirement doesn't apply to us.

Ah, yes, if your site is uncachable anyway, then that really is the way to go. Caching two copies isn't unreasonable I guess, but in the context of Rails (which is the unstated context of this solution), it's more of a pain in the ass than it's worth.

[Edit: I updated the post to be clear that this solution does work if your page is uncachable anyway.]

This is a big win when you use ESI, so your actual page content is cached separately from your header information. You can even push the decision about which asset links to use out to the edge. Goooooo Varnish!

/agree

"I won’t go into detail about how to actually accomplish this, because the truth is, this won’t work either. " => the truth is.. you fail ;)

But yeah, nice loading graph and +1 for the mathematical/logical alternative solution.

Good article

EdgeCast CDN offers dynamic gzipping. You can also force a cache miss/refresh by altering the query string, which is really helpful if you are changing content. They are a bit more expensive though (about 25% more). I also had to go through a sales/marketing person to get a trial, which is a shame because their product was actually better than CloudFront, but I almost didn't try it out because I hate going through sales people.

Reply on news.ycombinator.com