Return-Path: Delivered-To: apmail-httpd-dev-archive@www.apache.org Received: (qmail 87430 invoked from network); 2 Jun 2010 04:34:24 -0000 Received: from unknown (HELO mail.apache.org) (140.211.11.3) by 140.211.11.9 with SMTP; 2 Jun 2010 04:34:24 -0000 Received: (qmail 2767 invoked by uid 500); 2 Jun 2010 04:34:24 -0000 Delivered-To: apmail-httpd-dev-archive@httpd.apache.org Received: (qmail 2619 invoked by uid 500); 2 Jun 2010 04:34:23 -0000 Mailing-List: contact dev-help@httpd.apache.org; run by ezmlm Precedence: bulk Reply-To: dev@httpd.apache.org list-help: list-unsubscribe: List-Post: List-Id: Delivered-To: mailing list dev@httpd.apache.org Received: (qmail 2610 invoked by uid 99); 2 Jun 2010 04:34:22 -0000 Received: from athena.apache.org (HELO athena.apache.org) (140.211.11.136) by apache.org (qpsmtpd/0.29) with ESMTP; Wed, 02 Jun 2010 04:34:22 +0000 X-ASF-Spam-Status: No, hits=-0.0 required=10.0 tests=AWL,RCVD_IN_DNSWL_LOW,SPF_HELO_PASS,SPF_NEUTRAL X-Spam-Check-By: apache.org Received-SPF: neutral (athena.apache.org: local policy) Received: from [207.106.84.159] (HELO atlas.jtan.com) (207.106.84.159) by apache.org (qpsmtpd/0.29) with ESMTP; Wed, 02 Jun 2010 04:34:14 +0000 X-JTAN-Outgoing-From: sctemme@apache.org X-JTAN-Outgoing-To: X-JTAN-Received: c-67-188-201-250.hsd1.ca.comcast.net [67.188.201.250] X-JTAN-Recipient: X-JTAN-AntiSPAM: not spam, Outgoing not scanned X-JTAN-AntiVirus: Found to be clean, Outgoing not scanned Received: from [10.11.0.108] (c-67-188-201-250.hsd1.ca.comcast.net [67.188.201.250]) (authenticated bits=0) by atlas.jtan.com (8.12.8p1/8.12.8) with ESMTP id o524XpJ6005585 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT) for ; Wed, 2 Jun 2010 04:33:53 GMT Content-Type: text/plain; charset=iso-8859-1 Mime-Version: 1.0 (Apple Message framework v1078) Subject: Re: Fast by default From: Sander Temme In-Reply-To: <99EA83DCDE961346AFA9B5EC33FEC08B04003377@VF-MBX11.internal.vodafone.com> Date: Tue, 1 Jun 2010 21:33:50 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <4598591C-2DAD-4488-A8AA-035E4A34B761@apache.org> References: <99EA83DCDE961346AFA9B5EC33FEC08B04003377@VF-MBX11.internal.vodafone.com> To: dev@httpd.apache.org X-Mailer: Apple Mail (2.1078) All,=20 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. =20 On Jun 1, 2010, at 5:50 AM, Pl=FCm, R=FCdiger, 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. =20 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. =20 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.=20 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. =20= 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.=20 S. --=20 Sander Temme sctemme@apache.org PGP FP: 51B4 8727 466A 0BC3 69F4 B7B8 B2BE BC40 1529 24AF