Sander,
Sorry, missed your reply originally. I would assume that it is possible to
make configuration conditional and enable mod_gzip if zlib is available to
help distribution builders like Red Hat make this decision to include the
module?
BTW, it beats me why zlib is not in distros by default - gzip seems like a
very commonly used process ;)
P.S. this problem does not affect mod_expires and mod_rewrite I was
originally talking about - both don't need any additional libraries as far
as I know.
Sergey
On Wed, Jun 2, 2010 at 12:33 AM, Sander Temme <scte...@apache.org> wrote:
> All,
>
> I was once offered money to provide a high-performance Apache configuration
> file for a website. When I pointed out that I would need to come in,
> analyze their app and its performance, and then iteratively tune the config
> accordingly, I was given to understand that this was not necessary. Just
> send us the config, please. They were highly miffed when I didn't lay that
> particular flavor of golden egg for them. I actually got fired from that
> gig.
>
> On Jun 1, 2010, at 5:50 AM, Plüm, Rüdiger, VF-Group wrote:
>
> > And others have argued well to leave it off by default. My personal
> opinion is that we should leave it disabled by default for the reasons (CPU,
> Proxies, Browser behaviour, ETAG problem) mentioned by others.
>
> I thought it isn't in the default build because it requires an external
> library that may not be on the system. If this is not of concern, we might
> as well turn it on in the default build. Same for mod_ssl.
>
> Generally, I think we see the build and runtime configuration as a starting
> point from which to create your own environment, not a canonical default
> that is right for all (or even most) users.
>
> Distributors (Red Hat et. al.) should (and do) build httpd according to the
> capabilities of their environment. If that environment includes libz and
> openssl, no reason why packagers shouldn't build those modules. Including
> those features is good for their customers.
>
> As others have pointed out, a lot of performance tuning is highly site and
> situation specific. Once again the default configuration file cannot be
> expected to cover all possible situations. Deflate, caching, load
> balancing, proxying, content segregation, etc. can only be optimally
> configured only in the context of the individual deployment.
>
> If there were a silver bullet to making the web server "fast", don't you
> think we would have fired it some time in the past 15 years? There is no
> such thing. The only way to get a handle on it is to read the books, figure
> it out, or hire a consultant. But don't expect him to lay any golden
> performance eggs.
>
> S.
>
> --
> Sander Temme
> scte...@apache.org
> PGP FP: 51B4 8727 466A 0BC3 69F4 B7B8 B2BE BC40 1529 24AF
>
>
>
>
