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
|