httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Sander Temme <scte...@apache.org>
Subject Re: Fast by default
Date Wed, 02 Jun 2010 04:33:50 GMT
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
sctemme@apache.org
PGP FP: 51B4 8727 466A 0BC3 69F4  B7B8 B2BE BC40 1529 24AF




Mime
View raw message