I have mod_gzip installed on all of my servers now and I am just wondering if there are any downfalls..it seems too good to be true. Anyone know anything I don't?

Travis Rowland

i was also wondering that

i have never heard any cons either

It takes some CPU to do all the on-the-fly compressing, but I hear the benefits are very well worth the little CPU that it does use.

The only con is that sometimes you'll get someone running a script that goes into an infinite loop of outputting data, and mod_gzip will keep trying to compress the output till it's filled up /tmp then Apache will just stop.

What about consistency in terms of successfully outputting the page? I've heard stories of how for some visitors, content appear garbled up. That's the main thing holding me back from turning the feature on.

No problems so far...

Been running mod_gzip on all the servers for well over a year and have had zero problems thus far. Many, many sites and not one complaint.

mod_gzip is good tool.

Have a nice day
:)

Originally posted by FloHost
I have mod_gzip installed on all of my servers now and I am just wondering if there are any downfalls..

There is supposedly some sort of conflict between mod_gzip and SSL, but I have yet to experience any problems with them personally.

-Bob

Which browsers currently support pages using mod_gzip?

What KDAWebServices says is the reason I don't use mod_gzip any longer. One rogue PHP script looping infinitely and your services are denied.

It also takes a bit of ram to load the module in apache.

We have a cron job that checks disk space every 5 minutes in /tmp and nukes the .wrk files that mod_gzip can leave behind if it causes Apache to crash.

My servers use 40% less bandwidth on average and the sites are 40% faster. I absolutely love it! I can not be more pleased, it did seem to be too good to be true but now you people have cleared up this for me. I really appreciate it, thank you.

Travis Rowland

Originally posted by KDAWebServices
We have a cron job that checks disk space every 5 minutes in /tmp and nukes the .wrk files that mod_gzip can leave behind if it causes Apache to crash.

Yeah. We had same problem before and had to setup cron job to eliminate the problem. One of our private server, we had to remove mod_gzip completely, .wrk can go very wild within a few seconds.

thats wierd, i dont get any wrk files with my mod_gzip

You do, trust me, it's just that mod_gzip by default deletes them when it's done. But if a script is endlesly creating output, mod_gzip never gets done, so the .wrk keeps growing in size till it has run out of disk space. It can fill a couple of Gb very quickly.

Yes I've been a victim of the infamous .wrk effect.
Basically nothing works on your server anymore because there is not a single byte free.

And even cron jobs can not be invoked often enough, because it only takes seconds to create a huge .wrk...:bawling:

actually, now that i think about it

i had someone write a bad php script, that filled up my /tmp and it was a wrk file. does doing open_basedir on their vhost limit their wrk file to their home dir? or is it wherever the mod_gzip tmp is?

Nick, I don't think that it would do any good.
The .wrk files are used, AFAIK, to create the compressed page, so it's not a PHP issue anymore at this point.

Hmmm...this certainly gives pause to using this feature on my site, esp since I plan on experimenting with PHP soon.

Thanks,

I use mod_gzip on one server and had problems with a client who used IE5.1 on a MAC (PC is fine as are othewr browsers, IE and netscape etc on a MAC) - Web pages would not load, outputting the error "cannot stat gzip compressed"

All sites on the server were unviewable to him - That's the only problem I have experienced with it - The benefits are great. :D

Originally posted by KDAWebServices
....and mod_gzip will keep trying to compress the output till it's filled up /tmp then Apache will just stop.

We moved /tmp to /home and never had such problems.
Once mod_gzip created 2Gb of .wrk files in /tmp , but our /home was about 20Gb :) Then the script was auto_stopped.

Ha yes...good point: ulimit seems to be your saviour here...

To avoid work files, you can disable them from being created. To avoid long running, rouge scripts from looping forever, you should have limits set in your web server configuration to prevent this anyway. A process that's allowed to run without any control or limits can do worse damage than create large work files.

Finally, there was some mention of SSL, but I haven't heard anything about this for at least a year now. All in all, the gzip module is a great thing and you can disable or configure how it works and the web server very simply to avoid those problems I've seen reported in this thread.

Pls let me know if there is any step by step guide to installing mod_gzip on RH7.2 box.

It's claimed by the makers of mod_gzip that their mod_hs is way far better than mod_gzip. Does anyone use mod_hs?

http://forum.plesk.com/showthread.php?s=&threadid=331&highlight=Loaded+DSO+libexec%2Fmodgzip.so