Web Hosting Talk : Web Hosting Main Forums : Web Hosting : Mod_Gzip Refused by Host

[chrisb]

I ask my host if they had mod_gzip installed, and if not, would they please install it, and here is the answer I received...

"mod_gzip is not installed and will not be. Too much CPU overhead for a shared hosting environment."

Is this true? Does mod_gzip really cause too much CPU overhead for shared hosting?

[DanielP]

Depending on the load of the server yes. You figure its going to compress every file 100k and smaller for thousands if not hundreds of thousands of page views a day.... so yes it could easily double the load on a server althou I'd say normally you'd look @ a 25% increase, but these are rough estimates as I've never played with it in a controled test enviroment

[Paul_9cy]

Well it can hit the cpu hard if in use alot but if its done right it can realy reduce bandwidth....

This CPU usage is a valid reason but the server's must be doing some heavy loading.

Mod_gzip can run in php without it being installed on the server mind.

[2host.com]

People seem to get too confused about this when they think about compression and how it serves up the files. It takes CPU time to serve up the larger files, the compression ratio is faster on CPU time to compress and serve up these files types, than it is on CPU time to serve up a larger file. This is not a valid excuse and if it's set up properly it will not cause any disadvantages at all. It will actually remove load from your CPU when serving up the files. If you are paranoid or uneducated about compression and how it all works and how files are served up, please research it, otherwise you will miss out on a great module by assuming it must equate to using more CPU to compress the file.

[chrisb]

Originally posted by 2host.com
People seem to get too confused about this when they think about compression and how it serves up the files. It takes CPU time to serve up the larger files, the compression ratio is faster on CPU time to compress and serve up these files types, than it is on CPU time to serve up a larger file. This is not a valid excuse and if it's set up properly it will not cause any disadvantages at all. It will actually remove load from your CPU when serving up the files. If you are paranoid or uneducated about compression and how it all works and how files are served up, please research it, otherwise you will miss out on a great module by assuming it must equate to using more CPU to compress the file.

Thanks Robert. Do you have any documentation from a reputable source that I can send to my host that supports your statements that mod_gzip uses less CPU power, not more?

[2host.com]

Originally posted by chrisb

Thanks Robert. Do you have any documentation from a reputable source that I can send to my host that supports your statements that mod_gzip uses less CPU power, not more?

Well if they have knowledge of it, it will stand to reason. However I believe that the mod_gzip site itself actually has some information about this. They mention it on their site, but people seem to want to claim it's just an empty, unproved claim. But they also have links. Further web site searches about this topic will find more compelling support. However keep in mind that there's a lot of paranoid people claiming things in opposition too (and think it's just too good to be true and there has to be something that will fault).

[Techark]

Yes I would like to see that document also. I installed it one of my servers after reading all the great things on it here and saw load increases of 25 to 40% right away. I have decided to not install it on my other servers. While it does lower the bandwidth and speed the download it also seems to cause a larger strain on the server from what I have seen.

Now I will admit I am not that knowledgable of it so I may not have it optimized. If there is someone that can show me some place that details how to do that I would love to see it.

[Jedito]

I have so problem with mod_gzip and Tomcat (specially if I run tomcat through mod_jk), seems like they don't like each other, so, I had to remove mod_gzip .

[chrisb]

Is it possible to load mod_gzip in my own directories without root access to test it out?

[DanielP]

Well, if you want to get fancy you could compile your own copy of apache... you should have enough user privelages to do so, you'd just have to run it on an empty port.

Also as mentioned as above with php you can run it gzip compressed without mod_gzip installed.

[AceWeb]

Originally posted by chrisb
Is it possible to load mod_gzip in my own directories without root access to test it out?

No, at least as far as I know you cannot.

[chrisb]

Hey, Deb, just wondering if futurequest has mod_gzip turned on???

[Webdude]

I must have security too high on our machines, or too many specialized modules...definitely something. Even the mod_gzip developers couldnt get it to work on our machines. They finally gave up. I dunno either. I really wish they could have gotten it to work. I was really interested in seeing how much bw it saved us, then switch to mod_hs and see if that saved us even more.

Too bad. Mod_hs (newer and supposedly far better version of mod_gzip) is $1500 per CPU (that's $3000 per machine for us). I decided that at this time I wasnt interested in spending that much if I cant even compare it to mod_gzip in a live environment to see for myself how much better it is. It was interesting that they could get mod_hs to work, but not mod_gzip. I didnt try it though..

[bitserve]

Like robert said, the longer the file transfer, the more that gzip will save you on cpu, because the cpu will be utilized more at the beginning but it will be utilized for a shorter period of time overall.

At some exponential point, things will equal out or actually improve.

For very short transfers, you will just have higher cpu at the beginning, and not get the exponential savings of having it run for a shorter time.

There are basically two things that determine the length of the transfer. The speed of the transfer and the size of the file.

mod_gzip should be set up to only compress files over a certain size.

You can't control the speed, but you would see more savings compressing files for your 56Kb customers than your 1.2Mb customers. Most 56Kb modems are already using compression though, so somewhere down the line, your modem vistors aren't equal to your non-modem 56Kb visitors.

For most instances, you will probably only want to compress text files, and not binaries that will already be compressed, if they're being streamed from a web site, anyway.

You should also compile mod_gzip on your machine, and not use any precompiled binaries.

It's understandable that your host would not want to install mod_gzip, as ultimately the bandwidth bill is being passed onto you, the customer. Typically "special" configurations in a shared environment aren't going to be available. That's shared hosting for you. Also, you should expect to pay an hourly rate for the special configuration and any support required if they actually enabled it for you.

[mdrussell]

Unfortunately the calculation that compression and transmission of a file is easier on the CPU than the transmission of a larger file seems to be somewhat theoretically based - like Monte, in use we found mod_gzip to put a higher load upon the CPU, and it seemed to cause Apache to crash on a more frequent basis.