[Mod_gzip] mod_deflate (Apache 2.0.x)

[mod_gzip@lists.over.net]

Hi Stephen...
This is Kevin Kiley...

> Ok all, it's crow eating time for yours truly.
>
> Earlier this week, I said some less than positive things about 
> mod_deflate on this list. Now it's time to take them back. In working 
> with Ian Holsman, the author of mod_deflate, we tracked down the source 
> of my complaints.

Super! 

Kudos to Michael Schroepl ( of mod_gzip list ) for helping
you focus on the 'issue'. I am glad the mod_gzip list could help
you with mod_deflate.

As I have been known to point out before... there is
nothing all that bad about mod_deflate. It works.

mod_deflate represents a huge positive step
forward for the Apache Server group... at least there is
FINALLY something that is shipped with the Server that
can perform RFC standard Content-Encoding for non-static
content. This is a GOOD THING.

My opinion is that if you can find ANYTHING that helps
you reduce your content on the wire ( free or commercial )
then by all means you should be USING it. Doesn't matter 
WHAT it is as long as it fits your needs.

Until more people ( like yourself ) actually start using 
mod_deflate to discover flaws ( if any ) and/or features it 
might be missing it stands no chance of improving.

mod_deflate was sort of a 'rush job' in the grand scheme
of things and while it went through the normal 'submit and
review' process at Apache it was on an accelerated 
timeframe and there really hasn't been that much hard-core
testing of it before it was moved out of the 'experimental'
directory in the Apache source code tree.

> mod_deflate had been written for Best SPEED 
> not Best COMPRESSION. Once a few of us hammered 
> this out, the function call was located and tested 
> and voila! instant fix for mod_deflate.

Fantastic!... but I wouldn't go so far as to say (all of) mod_deflate
was 'written for Best SPEED'. It is the single ZLIB API
call parameter called 'BEST_SPEED' versus 'BEST_COMPRESSION'
that you are referring to. It is ( was? ) a hard-coded constant
in mod_deflate. I am known to hold the opinion that if mod_deflate 
was really concerned with 'BEST_SPEED' then it wouldn't be 
using ZLIB at all. ZLIB was never designed to be used as a 
real-time in-memory compression engine. It is still, essentially, 
just a file-based compression library with some stream-level 
APIs added.

> Ian committed a patch to the main Apache tree, that should appear with 
> ver. 2.0.45, adding a directive called CompressionLevel. 

I haven't seen the patch appear for comment/review at Apache.org
development site (yet?). AFAIK a change like that MUST be presented
for group review at Apache since it invloves a 'new directive'.

> Details of the bridge hack you can perform and CompressionLevel 
> directive can be found at:
>
> http://www.webcompression.org/mod_deflate-hack.php
>
> I apologize to the Apache 2.0 team for any offense my comments 
> may have given. My Apache 2.0.44 server is now happily running 
> mod_deflate.

You seem to usually be quite a diligent 'tester', based on your other
postings and your public websites, so I was curious to know if
you have done any 'load testing' using the 'higher' compression
rates? There might still be a REASON why 'ZLIB' is/was being
called by mod_deflate using the least amount of compression
but the greatest 'speed'. The ZLIB 'compression levels' require
an increasing amount of CPU time the higher they get ( it is
somewhat geometric in scale ) and when trying to use ZLIB 
as a real-time compression engine for a heavily loaded Server 
this should ALWAYS be a consideration. 

If your Server isn't very busy then it doesn't really matter...
nothing is going to 'bog down' and the user gets the 
best compression... a good deal!

If you run into any other 'issues' with mod_deflate please don't
hesitate to re-post. Despite the name of this forum I think
everyone here is simply interested in helping people with
their content compression needs. I know I don't just speak
for myself in that regard.

Yours...
Kevin Kiley