Slashdot Mirror
Webaccelerator with mod_gzip ?
Christian Bjerre writes: "Currently I'm using Squid as an webaccelerator to sit infront of apache and serve static files (.html .js .gif .png .jpg). Squid also serves my dynamic content which is .php files. My goal is to let Squid or another opensource program gzip the html, since I have Squid installed on another machine, where cputime is not an issue. I've been reading page up&down and Squid dosen't seem to support gzip encoding in Webaccelerator mode. I haven't tried feeding it gzipped html, which could be a solution, if there was a way of having Squid handle all content as binary. What do you guys & girls do to minimize bandwidth usage? // chris"
Yeah, whatever but right now network bandwidth is fscking expensive. OTOH I'm not sure that an appreciable quantity of the bandwidth from a website is actually text.
FWIW these guys use php's ob_gzhander function and appear to get quite good results.
Dave
I write a blog now, you should be afraid.
Slashdot uses mod_gzip (watch your connections sometime if you don't believe me), so apparently they decided CPU time was cheaper than bandwidth, at least on very large scales.
That should be endorsment enough, right?
Apache+mod_proxy+mod_cache can also be an httpd accelerator (aka reverse proxy) and I've had great success with it. My original configuration used Squid but several limitations with Squid forced me to investigate the alternatives. I finally settled on Apache and I've been very happy with it. Apache also has better support for 301/302 rewriting (the PassProxyReverse directive) than Squid, and this was a deciding factor for me in dumping Squid and going with Apache.
Well, I don't think you realize how much bandwidth is saved. My stats before gzip say 329,391 pages for 3.2 gigs. January (after gzip) was 285,289 pages, and 1.2 gigs. So I can serve out 4 times as many pages a month and still make our 5 gig quota.
Personally though, I think the whole HTTP compression thing is overblown - causes more problems than it solves sometimes, and if you're compressing to please modem users, I'd prefer to simply put a banner on my site saying "Burn your modem, you fewl".
I work as the lead programmer for a (somewhat) large e-Business application, and I can honestly say that gzip compression is definitely worth it.
In our case, the application is Java-based. It was a piece of cake to add dynamic gzip compression to the 'main' servlet which every other servlet in the application extends. For us, it was important to see how quickly a page can be sent to our customers. Even a small gain would improve things a lot.
The results? Well - after some testing, we figured out that for any pages greater than 8k in size, it's worth the extra time to compress with gzip. We've saved a bundle in bandwidth costs, and more importantly, customers are happier that they can download their (large - a couple hundred k) reports in a decent timeframe, for example.
I've had no trouble with it either. The only case where it had issues was when the content wasn't textual, such as dynamically-generated PDF documents. The browers didn't know what to do with this, so some care had to be taken to only use gzip on the html and text content. Naturally we check the accept-encoding in the http request headers to make sure it's ok.
Many companies who are our customers don't have T1s, after all. Quite a few have ISDN. The thing is, you can't get them to listen and spend more money on a pipe just so they can use the advanced (bandwidth-intensive) features of your site. Instead, you have to do what you can to accomodate them as much as possible.
The gzip compression actually made the site bearable even on a 28.8. Thus, customers who have faster lines benefit even more, since our own pipe is less clogged as a result too.
We can always throw an extra machine or two into our application server pool (relatively cheap for a simple 1U server). Adding extra bandwidth, though, is expensive and management has already forbidden it for the time being.
You can accomplish anything you set your mind to. The impossible just takes a little longer.
There is an article on php's output buffering (which includes compression)here
There are also a collection of third party class's which you can browse here.