tomcat-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Pid *" <...@pidster.com>
Subject Re: mod_jk connection pool configuration
Date Fri, 18 Nov 2011 08:14:25 GMT
On 17 Nov 2011, at 20:39, Christopher Schultz
<chris@christopherschultz.net> wrote:

> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> Pid,
>
> On 11/16/11 7:20 PM, Pid wrote:
>> What I'm not clear on is whether the mod_jk worker
>> connection_pool_size is 60 per Server child, or 60 * 10 Server
>> children.
>
> mod_jk's connection_pool_size, when left to the default (which I think
> everyone should do) will auto-size for the situation.

Auto-size or select-at-startup? I thought the latter, and that in
worker mpm it derived from ThreadsPerChild.

At least that's how I read the docs & Mladen / Rainer's previous
statements on the topic.


> Obviously, in
> the prefork MPM, it defaults to 1 because you simple can't make more
> than one connection. For the worker MPM, I think the default is one
> connection per thread (per worker, of course), so if you have 600
> total threads, you'll have 600 threads * 20 connections each = 12000.

Right... but if MaxClients is 600 that's a lot of unused & open connections, no?


> You can, of course, limit the number of connections by setting
> connection_pool_size to something smaller than the total number of
> threads * Tomcats you have. You'd only really want to do that if you
> were expecting a lot of requests to be handled directly by httpd with
> no communication with Tomcat.
>
> If you have 10% of your traffic going to Tomcat, then you might want
> to have your connection_pool_size set to 60 instead of (defaulting to)
> 600.

I thought it defaults to 60 but becomes 600 in total because there are
10 pools, one for each worker.


>
>> If MaxClients is still 600 and there is one Tomcat, one might
>> assume that allowing all 600 to go to that Tomcat is  sensible -
>> but if there are two Tomcats, what is the behaviour?  NB 600 to
>> each Tomcat would be more than MaxClients.
>
> mod_jk isn't affected by MaxClients, of course (aside from possibly
> the auto-default of connection_pool_size).

Correct, but if MaxClients is 600, what's the point of having more
connections open to the backend Tomcat(s)?


> If you have 600 worker
> threads and 1 Tomcat, I would expect 600 persistent connections from
> httpd to that one Tomcat instance. Doubling the number of Tomcat
> instances (by adjusting the worker, for example, to be an lb) will
> result in doubling the number of backend connections to 1200.
>
>>> If you have more than one worker, then the number of Tomcat
>>> instances is essentially multiplied. So, if you have 20 TC
>>> backends each with 2 workers assigned to them, then you'll 24000
>>> connections instead.
>>>
>>>> Will this change If Tomcat instances start failing?
>>>
>>> Probably not -- mod_jk will just retire the connection and create
>>> a new one. If you are having load problems, you might make things
>>> worse with all this connection churn.
>>
>> Agreed.
>
> So, what was the problem you were trying to solve in the first place?

I saw behaviour I didn't expect at a customer. Made more complicated
by other factors, so I wanted to clarify the expected behaviour.


> Or, was this a capacity-planning Gedankenexperiment?
>
> - -chris
>
> PS Missed you (again) at ApacheCon. Get on a plane you lazy bum.

Yeah. :(. Unavoidable customer work.


> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG/MacGPG2 v2.0.17 (Darwin)
> Comment: GPGTools - http://gpgtools.org
> Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
>
> iEYEARECAAYFAk7FcNcACgkQ9CaO5/Lv0PCIGACfbMFvTIacHTCO2sFavOSL2dzS
> pd4AoLbsnhHNclExBJ2TsyZN5ZA61JO6
> =xePs
> -----END PGP SIGNATURE-----
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: users-help@tomcat.apache.org
>

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org


Mime
View raw message