Return-Path: Delivered-To: apmail-httpd-users-archive@www.apache.org Received: (qmail 56279 invoked from network); 14 Jul 2010 11:17:52 -0000 Received: from unknown (HELO mail.apache.org) (140.211.11.3) by 140.211.11.9 with SMTP; 14 Jul 2010 11:17:52 -0000 Received: (qmail 71911 invoked by uid 500); 14 Jul 2010 11:17:49 -0000 Delivered-To: apmail-httpd-users-archive@httpd.apache.org Received: (qmail 71741 invoked by uid 500); 14 Jul 2010 11:17:45 -0000 Mailing-List: contact users-help@httpd.apache.org; run by ezmlm Precedence: bulk Reply-To: users@httpd.apache.org list-help: list-unsubscribe: List-Post: List-Id: Delivered-To: mailing list users@httpd.apache.org Received: (qmail 71728 invoked by uid 99); 14 Jul 2010 11:17:44 -0000 Received: from nike.apache.org (HELO nike.apache.org) (192.87.106.230) by apache.org (qpsmtpd/0.29) with ESMTP; Wed, 14 Jul 2010 11:17:44 +0000 X-ASF-Spam-Status: No, hits=0.0 required=10.0 tests=FREEMAIL_FROM,SPF_PASS,T_TO_NO_BRKTS_FREEMAIL X-Spam-Check-By: apache.org Received-SPF: pass (nike.apache.org: domain of trawick@gmail.com designates 209.85.160.173 as permitted sender) Received: from [209.85.160.173] (HELO mail-gy0-f173.google.com) (209.85.160.173) by apache.org (qpsmtpd/0.29) with ESMTP; Wed, 14 Jul 2010 11:17:38 +0000 Received: by gyf2 with SMTP id 2so4183852gyf.18 for ; Wed, 14 Jul 2010 04:17:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:content-type; bh=Q6Ms+qTfkyYhkm+20FkXwfnZa1N8ZM45h8d46KFHCkY=; b=m3rn+NjM4Wy4ZGfl3XWlcGwv0nlf5vfnLyDyIh2NeBr5wCdmL+kHwcTCDf5vY9iKmp RLTUOp7vXjfilSlXbdEqAdgQPRWkLfKTMMEXh1EvvdiL+gh0S2/VWjhtBZKMls3kmCNa FRvZuABVz/DX3uBnrIs+PXQCpPNkB1BxeReoE= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; b=s68DYHnv1LhWk8WY5ZEe9TIYJpKsVJwihMv1vZAe+xudVXdCCqR7crADCWoHmHRbvn Lqq2KUBGqZ+9MvmnQYAF/HolSMx3a53DhmXA78fDNYeHKC18Dv634S3yLc7dwHq4ddjg 9MiWpA0ddhgFZkBB1fVJSgi/u6EDYl2y90Py0= MIME-Version: 1.0 Received: by 10.100.153.5 with SMTP id a5mr18544991ane.12.1279106237038; Wed, 14 Jul 2010 04:17:17 -0700 (PDT) Received: by 10.100.239.7 with HTTP; Wed, 14 Jul 2010 04:17:16 -0700 (PDT) In-Reply-To: References: Date: Wed, 14 Jul 2010 07:17:16 -0400 Message-ID: From: Jeff Trawick To: users@httpd.apache.org Content-Type: text/plain; charset=ISO-8859-1 X-Virus-Checked: Checked by ClamAV on apache.org Subject: Re: [users@httpd] mod_proxy: ProxyPass max parameter has no effect On Tue, Jul 13, 2010 at 8:42 PM, Alessandro Vernet wrote: > Igor, > > I am running Apache 2.2.14. Re-reading the documentation for "max", I see: > > The default for a Hard Maximum for the number of connections is the > number of threads per process in the active MPM. In the Prefork MPM, > this is always 1, while with the Worker MPM it is controlled by the > ThreadsPerChild. > > So the default of max in prefork MPM is 1, which doesn't make any > sense unless you understand this as "1 per Apache process". So maybe > with prefork, the value of max is per process. Since my understanding > is that in prefork there each concurrent request is handled by a > different process, that max parameter would be useless in prefork MPM. > (Hopefully my understanding is not correct!) > > Alex > > On Fri, Jul 9, 2010 at 5:10 PM, Igor Cicimov wrote: >> Hmmmm I had to read the documentation again my self and I can't find any >> mention of what type of MPM is supported in this case. All it says is >> "Apache will never create more than the Hard Maximum connections to the >> backend server" so it makes me expect that max parameter should be in force >> no matter what MPM is in use. But having in mind Eric's comment looks like >> this is not communicated across different processes and since every thread >> is a new process in MPM prefork the max setting will fail. I'm not sure how successful I was, but I recently tried to clarify this multi-process issue in the trunk documentation (http://httpd.apache.org/docs/trunk/mod/mod_proxy.html#proxypass). It seems to be a common confusion, regardless of the level of experience of the user. In fact proxy *could* share the pool limits across MPM child processes. However, it wouldn't be practical to share the connection pool itself, and I think it would be harmful to share the limits without sharing the pool. So this proxy connection pool is probably a permanent consideration for the choice between one child process with lots of threads vs. multiple child processes with smaller numbers of threads. 2-3 child processes with a somewhat large number of threads is probably close enough to the simplest/one-child-process solution to be able to reasonably configure the pool to match the backend capacity. But as there is usually no fairness in the utilization of httpd front-end processes, except when the capacity closely matches the client load, increasing the number of httpd child processes, and thus the number of connection pools, results in underutilized pools, or underutilized slices of the overall capacity. --------------------------------------------------------------------- The official User-To-User support forum of the Apache HTTP Server Project. See for more info. To unsubscribe, e-mail: users-unsubscribe@httpd.apache.org " from the digest: users-digest-unsubscribe@httpd.apache.org For additional commands, e-mail: users-help@httpd.apache.org