You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@tomcat.apache.org by Pid * <pi...@pidster.com> on 2011/11/16 14:47:32 UTC
mod_jk connection pool configuration
Hi,
Tomcat 6.0.32, HTTPD (worker mpm) 2.2.19, mod_jk 1.2.31.
If ThreadsPerChild is 60 and ServerLimit is 10, MaxClients is 600, how
many connections, at peak, will be made to 20 Tomcat instances?
Will this change If Tomcat instances start failing?
p
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: mod_jk connection pool configuration
Posted by Pid * <pi...@pidster.com>.
On 16 Nov 2011, at 13:47, Pid * <pi...@pidster.com> wrote:
> Hi,
>
> Tomcat 6.0.32, HTTPD (worker mpm) 2.2.19, mod_jk 1.2.31.
>
> If ThreadsPerChild is 60 and ServerLimit is 10, MaxClients is 600, how
> many connections, at peak, will be made to 20 Tomcat instances?
I should add that 'connection_pool_size' is not set in workers.properties.
>
> Will this change If Tomcat instances start failing?
>
>
> p
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: mod_jk connection pool configuration
Posted by Christopher Schultz <ch...@christopherschultz.net>.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Pid,
On 11/18/11 3:14 AM, Pid * wrote:
> On 17 Nov 2011, at 20:39, Christopher Schultz
> <ch...@christopherschultz.net> wrote:
>
> 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.
I'm not sure I see the distinction. connection_pool_size defaults (or
auto-sizes) to ThreadsPerChild which essentially means that for an
httpd process, each thread has a connection waiting for it in the pool.
> Right... but if MaxClients is 600 that's a lot of unused & open
> connections, no?
Well, it depends upon your expected load. You should see what kind of
pool utilization you are getting (dunno if mod_jk can log that -- you
can probably do some crude scanning of your access logs and see what
kind of Tomcat access rate you are getting) and size your connection
pool(s) accordingly.
> I thought it defaults to 60 but becomes 600 in total because there
> are 10 pools, one for each worker.
I think it's ThreadsPerChild * Children * Workers. So that's 60 * 10 *
20 = 12000 total.
> Correct, but if MaxClients is 600, what's the point of having more
> connections open to the backend Tomcat(s)?
Because you might need 600 connections to any one Tomcat backend at
any time. And that backend choice isn't predictable. So you need 12000
so there's never any waiting.
Certainly, you know more about your setup and expected traffic than
mod_jk's defaults, so feel free to override the connection_pool_size
- -- possibly even on a per-worker basis.
>> 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.
Well, everything I've said here is what *I* would expect... not
necessarily what will really happen :) I only play a mod_jk expert on TV.
Do my expectations match what you are observing in this case?
- -chris
-----BEGIN PGP SIGNATURE-----
Version: GnuPG/MacGPG2 v2.0.17 (Darwin)
Comment: GPGTools - http://gpgtools.org
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
iEYEARECAAYFAk7Gc0oACgkQ9CaO5/Lv0PDOIQCgje+Rws2+aQ1kwYuWZYqfbD0C
mO8AoLF50vTXhtvcs1OH5ReO/0BphHA6
=KkBC
-----END PGP SIGNATURE-----
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: mod_jk connection pool configuration
Posted by Pid * <pi...@pidster.com>.
On 17 Nov 2011, at 20:39, Christopher Schultz
<ch...@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
Re: mod_jk connection pool configuration
Posted by Christopher Schultz <ch...@christopherschultz.net>.
-----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. 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.
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.
> 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). 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?
Or, was this a capacity-planning Gedankenexperiment?
- -chris
PS Missed you (again) at ApacheCon. Get on a plane you lazy bum.
-----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
Re: mod_jk connection pool configuration
Posted by Pid <pi...@pidster.com>.
On 16/11/2011 16:52, Christopher Schultz wrote:
> Pid,
>
> On 11/16/11 8:47 AM, Pid * wrote:
>> Tomcat 6.0.32, HTTPD (worker mpm) 2.2.19, mod_jk 1.2.31.
>
>> If ThreadsPerChild is 60 and ServerLimit is 10, MaxClients is 600,
>> how many connections, at peak, will be made to 20 Tomcat
>> instances?
>
> - From httpd docs:
>
> MaxClients: For threaded and hybrid servers (e.g. beos or worker)
> MaxClients restricts the total number of threads that will be
> available to serve clients. The default value for beos is 50. For
> hybrid MPMs the default value is 16 (ServerLimit) multiplied by the
> value of 25 (ThreadsPerChild). Therefore, to increase MaxClients to a
> value that requires more than 16 processes, you must also raise
> ServerLimit.
>
> ServerLimit: With worker use this directive only if your MaxClients
> and ThreadsPerChild settings require more than 16 server processes
> (default). Do not set the value of this directive any higher than the
> number of server processes required by what you may want for
> MaxClients and ThreadsPerChild.
>
> So if MaxClients is 600 and ThreadsPerChild is 60 then you can't have
> more than 10 processes each with 60 threads. If you want more than 16
> server processes (which it looks like you don't need), then you'll
> need to set ServerLimit to something higher than it's default for
> worker which appears to be 16.
>
> I'm not sure you need ServerLimit at all.
>
> If you have 20 TCs on the back end, then mod_jk will have to open 20 *
> 600 = 12000 connections at peak, if my math is correct. That's only
> 600 connections per TC, or course, but you may have trouble with
> creating that many connections from the proxy.
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.
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.
> 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.
p
> -chris
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: users-help@tomcat.apache.org
>
--
[key:62590808]
Re: mod_jk connection pool configuration
Posted by Christopher Schultz <ch...@christopherschultz.net>.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Pid,
On 11/16/11 8:47 AM, Pid * wrote:
> Tomcat 6.0.32, HTTPD (worker mpm) 2.2.19, mod_jk 1.2.31.
>
> If ThreadsPerChild is 60 and ServerLimit is 10, MaxClients is 600,
> how many connections, at peak, will be made to 20 Tomcat
> instances?
- From httpd docs:
MaxClients: For threaded and hybrid servers (e.g. beos or worker)
MaxClients restricts the total number of threads that will be
available to serve clients. The default value for beos is 50. For
hybrid MPMs the default value is 16 (ServerLimit) multiplied by the
value of 25 (ThreadsPerChild). Therefore, to increase MaxClients to a
value that requires more than 16 processes, you must also raise
ServerLimit.
ServerLimit: With worker use this directive only if your MaxClients
and ThreadsPerChild settings require more than 16 server processes
(default). Do not set the value of this directive any higher than the
number of server processes required by what you may want for
MaxClients and ThreadsPerChild.
So if MaxClients is 600 and ThreadsPerChild is 60 then you can't have
more than 10 processes each with 60 threads. If you want more than 16
server processes (which it looks like you don't need), then you'll
need to set ServerLimit to something higher than it's default for
worker which appears to be 16.
I'm not sure you need ServerLimit at all.
If you have 20 TCs on the back end, then mod_jk will have to open 20 *
600 = 12000 connections at peak, if my math is correct. That's only
600 connections per TC, or course, but you may have trouble with
creating that many connections from the proxy.
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.
- -chris
-----BEGIN PGP SIGNATURE-----
Version: GnuPG/MacGPG2 v2.0.17 (Darwin)
Comment: GPGTools - http://gpgtools.org
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
iEYEARECAAYFAk7D6mAACgkQ9CaO5/Lv0PCwSACfaDMyMVnj5GhMEhRgnH07R2Hh
/EEAnAyqpjnZSDmbnZrHxwC5BMSC1tJ5
=vpRW
-----END PGP SIGNATURE-----
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org