On Wed, Jul 14, 2010 at 9:53 PM, Alessandro Vernet <avernet@xxxxxxxx> wrote: > 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. correct, any time you want to allow fewer backend connections than client connections > 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? worker or event ThreadsPerChild == MaxClients (and may as well set ServerLimit to 1) One child process is the simplest/most obvious case. I think it will still work close enough to the desired goal if you have 2-3 child processes which share the workload and connection quota. > > 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 > > -- Born in Roswell... married an alien... --------------------------------------------------------------------- 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
|