UBB.Developers Forums Community Development Programming PHP and Server-side Scripting Measuring zlib compression

UBB.threads 6.0 beta 5, UBB.classic 6.2.1.2, PHP 4.1.2, zlib 1.1.4, Apache 1.3.12, Linux Redhat 7.0.

I'm interested in measuring the traffic savings achieved by using zlib-compression.

Each Apache access log entry contains the size of the response content in bytes. For pages that are zlib-compressed, is this the compressed page size or the uncompressed page size?

(If there's a more appropriate place to post this, on this board or elsewhere, please move it or make a suggestion. []/forum/images/icons/smile.gif[/] )

hmm, i'd be interested in finding that out too.

An easy way to test this and get a rough estimate is to check file sizes with compression turned off and on in your control panel.

This page (before this post was made)
with compression: 3755 bytes / without compression: 21029

the forum summary (ubbthreads.php)
with compression: 4423 bytes / without compression: 30248

You get roughly a 80-85% savings on the html part of your forum, tho none on your graphics - this means the % will go down depending on how much of your site loads new graphics on new pages. The graphics do get saved in the user's cache once they are downloaded the first time, so savings go up with repeat customers []/forum/images/icons/smile.gif[/]

There is a hit on the server's cpu fpr doing the compression, so a busy site on a less-than-stellar server might need to have compression turned off.

wow, thats nice, as far as bandwidth thats saved, but yeah, with slow server specs.. hmm..

Thanks, Allen, I might try that.

But what I really need is to be able to measure the total traffic.

I wrote a simple Perl script which analyzes the access logs and produces daily, weekly and monthly totals and averages. But I don't know whether these stats reflect the compressed or uncompressed sizes.

I know that mod_gzip allows you to add the compressed size, uncompressed size and compression ratio to the access log. Maybe I should use that instead of zlib. It would probably be better anyway, since it would compress pages served from outside the scripts.

Server resource utilization shouldn't be an issue, since it's a dedicated server, but we have bandwidth contraints, so compression is a priority.

Up to you, zlib compression will compress all .php pages served as long as it is enabled in the php.ini []/forum/images/icons/smile.gif[/]

does it require a special browser to do decompression?

do you have a link?

why don't you make more efficient output (see my post in the version 6 feature suggestion thread) in the first place, instead of trying to compress it?