httpd-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jeff Trawick <>
Subject Re: [users@httpd] mod_proxy: ProxyPass max parameter has no effect
Date Wed, 14 Jul 2010 11:17:16 GMT
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
(  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:> for more info.
To unsubscribe, e-mail:
   "   from the digest:
For additional commands, e-mail:

View raw message