Re: mod_proxy: ProxyPass max parameter has no effect

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Jeff,

Thank you for the precisions, and for the updated documentation. Let
me make sure I understand this correctly.

The use case:

Simply put, when using Apache as a load balancer, I'd like to limit
the number of connections Apache makes to back-end servers. When
processing requests requires a fair amount memory on back-end servers,
there often isn't much benefit in going over 2 concurrent requests per
core per back-end servers, and or performance might even degrade when
going well over this. So I'd like to tell Apache: "don't send more
than, say, 4 concurrent requests per back-end server; if you have more
(e.g. because all back-end servers are busy, or you need to send the
request to a specific one because of the sticky session, and that guy
is already handling 4 concurrent requests), just queue it".

How to do it:

1. The config looks like (assuming AJP is used to Tomcat):

ProxyPass / balancer://mycluster/ stickysession=JSESSIONID|jsessionid
<Proxy balancer://mycluster>
    BalancerMember ajp://192.168.0.100:8009 max=4
    BalancerMember ajp://192.168.0.101:8009 max=4
    BalancerMember ajp://192.168.0.102:8009 max=4
    BalancerMember ajp://192.168.0.103:8009 max=4
</Proxy>

2. Prefork MPM can't be used for this.
3. On Windows, we're all good as winnt MPM creates only one process.
4. On UNIX, we need to use worker MPM, and need to make sure there is
only one process. This means we need to set ServerLimit to 1 (?).
[This point is a rather drastic requirements, as many organizations
won't want to recompile or use a different Apache than the one they
already have, which is likely to be the prefork on UNIX.]

Does this sound about right?

Alex

On Wed, Jul 14, 2010 at 4:17 AM, Jeff Trawick <trawick@xxxxxxxxx> wrote:
> On Tue, Jul 13, 2010 at 8:42 PM, Alessandro Vernet <avernet@xxxxxxxx> 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 <icicimov@xxxxxxxxx> 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 <URL:http://httpd.apache.org/userslist.html> for more info.
> To unsubscribe, e-mail: users-unsubscribe@xxxxxxxxxxxxxxxx
>   "   from the digest: users-digest-unsubscribe@xxxxxxxxxxxxxxxx
> For additional commands, e-mail: users-help@xxxxxxxxxxxxxxxx
>
>



-- 
Orbeon Forms - Web forms, open-source, for the Enterprise -
http://www.orbeon.com/
My Twitter: http://twitter.com/avernet

---------------------------------------------------------------------
The official User-To-User support forum of the Apache HTTP Server Project.
See <URL:http://httpd.apache.org/userslist.html> for more info.
To unsubscribe, e-mail: users-unsubscribe@xxxxxxxxxxxxxxxx
   "   from the digest: users-digest-unsubscribe@xxxxxxxxxxxxxxxx
For additional commands, e-mail: users-help@xxxxxxxxxxxxxxxx




[Index of Archives]     [Open SSH Users]     [Linux ACPI]     [Linux Kernel]     [Linux Laptop]     [Kernel Newbies]     [Security]     [Netfilter]     [Bugtraq]     [Squid]     [Yosemite News]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Samba]     [Video 4 Linux]     [Device Mapper]

  Powered by Linux