zlib.compression -- I silently enabled this at zlib.compression.level 1 for a few days on a production site, as a test.

We received a whopping 3 complaints in the test period, out of 1000's of users. Meanwhile, the output from the server dropped by over 60%!

All 3 users who complained complained of the same thing, noticable degradation of speed. One of the users I queried claimed his machine was a P4 something with 512 MB of RAM running XP.. how could he possibly have had a noticable decrease in speed, so bad he'd complain, I thought, so I turned it off (the server in question doesn't need it, as the 60% bandwidth savings equates to exactly $0 less hosting fees, so 3 users > no real reason to have it on).

3 users out of 1000's is nothing, really.. so I guess my question is.. why doesn't every site make use of this? I went around to a couple dozen sites I frequent, this time checking to see if it was sending me compressed pages, and none of them were, not a single one. Is there something wrong with it that everyone got the memo about except me? ;)

The reason that most sites don't use this is because the load on the server increases exponentially if you have a heavy user load.

In addition, compression is dependent on the client browser. If the browser can't handle compressed responses, you will get all sorts of interesting results.

Sorry, I should have mentioned in my original post that simple things like this I already looked into, obviously -- and my answers there lead to me doing this test run.

The site in question receives over 3 million requests a day, so it is by no means a 3-visit-a-day family photo site.

It is hosted on a dedicated system with specs well over what it requires, because the additional expense was negligable and it allows for growth. Personally, I feel any production site with non-negligable usage shouldn't be skimping on hardware, its just going to bite them later.

The CPU usage of all apache processes added together is 15-20% at *peak* times. With zlib.compression on at level 1, this increased by a measly 5%. Of one CPU, in a dual CPU system. Obviously, this isn't something to write home about.

As to incompatibility.. per the PHP manual, zlib.compression being on doesn't == always send compressed pages. For the page to be sent out compressed, the browser must include in its request headers a field describing what forms of compressed pages it understands. Therefore, any incompatibility is really the fault of a broken browser.

I field-tested the site using the latest IE, Opera, Mozilla and Netscape - all performed just fine, all properly sending headers and receiving compressed pages. Since 99.9% of web browsers use one of these 4 (and heck, 99% use IE), I can safely conclude that browser incompatibility is a non-issue, as well. Especially considering only 3 complaints were lodged about site usability, and all 3 were not 'unable to browse', just 'slower than it was', which I can safely attribute to user-side problems when you consider there are 1000's of users browsing this site a day, all quick to complain, and only 3 did.

So is there any other reason a site wouldn't make use of zlib.compression, considering the fact that, at least imho, CPU & RAM are way cheaper than bandwidth? Especially if you start talking long-term? There HAS to be something, this has to be something the big sites have looked into, right?

Originally posted by Kattilyn
So is there any other reason a site wouldn't make use of zlib.compression, considering the fact that, at least imho, CPU & RAM are way cheaper than bandwidth? Especially if you start talking long-term? There HAS to be something, this has to be something the big sites have looked into, right?

I don't know if this is the problem your client is having, but with compression enabled on the server any scripts you run can't be compressed until they're completed (and hence can't be sent to the connected client) - I'd imagine in the vast majority of cases this isn't a big deal, (wait a few extra seconds and then get the page all at once rather than getting it bit by bit for the same amount of seconds) but if you have a script that takes more than a few seconds to run and sends prts of the output while it runs (so the user at least sees *something*) - it just won't happen with mod_gzip (or equivalent) enabled, the server has to wait for the script to finish executing before it can compress the data and begin transmission.

The reason I bring this up as a possible cause of your clients problems is because I've written a PHP chat script - it just runs on the server, keeps the connection to the client machine opens and sends data as and when it's recieved by the other connected chatters (or from IRC - whcih it niftily interfaces with too :D) - the problem is if you have mod_gzip installed, because the script essentially never finishes execution (unless the user hits the "stop" button or similar) - it never gets gzipped, and hence nothing ever gets sent to the browser.

The solution: Turn off mod_gzip or forget about using the script.

It's probably not the cause of your clients complaint, but I'd say it's a definite possibility.

(It's a bit complicated, and I maybe haven't explained it as well as I could - ask me to clarify if I've been a bit unclear)

Either you're mistaken, or I'm reading php.net wrong.

From what I understand, you're describing ob_gzhandler.. which, I think, you can actually get around what you're describing by specifically telling it to "flush"(?).

But that's neither here nor there..

Every site I read, including php.net, say the preferred method of compressing pages is ini.zlib.compression. And while I could be mistaken, from what I gathered, zlib.compression being on makes it on-the-fly compress output.. as it is outputted.

I believe there is some delay because it doesn't send out the compressed output until it reaches a certain size, but on a large page with lots of output, it will send out a number of chunks, not wait until the script has finished execution before sending out anything.

But I could be wrong? Anyone? ;)

You are correct. gzip is a streamable compression, so it can output chunks as it goes. (As opposed to zip or uz compression, which can't be processed until the full file is downloaded.)

I'm not sure if this is still the case, but last I tried it, a server-side include of a php page would embed the compressed gibberish into the parent page.

Originally posted by hiryuu
You are correct. gzip is a streamable compression, so it can output chunks as it goes. (As opposed to zip or uz compression, which can't be processed until the full file is downloaded.)

I'm not sure if this is still the case, but last I tried it, a server-side include of a php page would embed the compressed gibberish into the parent page.

You guys sure about that? It certainly sounds like a much better way of doing things than I mistakenly assumed - I guess I jumped to that conclusion because the chat script sends so little to the client it never completed a chunk (I've never had it in a busy IRC channel, or with more than a few people helping test *while* I've had mod_gzip on - for obvious reasons... namely I thought it didn't work :D)

So in that case my original point is still *kinda* right - if you've got a script heavy on the processing and low on the output mod_gzip would make it a very boring experience for the browser... I can't think of many scripts (other than chats) that fit that description though.

Oh well, thanks for the knowledge, you learn something new every day :)

where can i read some information about zlib.compression?

At php.net - search the 'whole site' for zlib.compression, you'll get back a number of relevant entries.