tomcat-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Rainer Jung <>
Subject Re: JK and IIS - troubles?
Date Fri, 03 Oct 2008 13:36:24 GMT
br1 schrieb:
> Rainer Jung-3 wrote:
>> That might be the reason for trouble. If things start to get slow, the 
>> web server gets filled by all thenew requests still coming in without 
>> answering fast enough the existing ones. 
> This starts to make sense now. 
> I have a few suggestions inline, I would like to contribute to document a
> case like this, if possible. 

If you like, we are always keen on helpful documentation. Maybe a page
about sizing connection pool and the relation between connections, web
server processes, IIS workers and Tomcat threads, measuring your needs
and the dangers arising from going to far.

> Rainer Jung-3 wrote:
>>  People often try to work around 
>> this by increasing the number of threads available for processing the 
>> requests, 
> Yes, some of us might still be used to old JK connectors defaulting to 10
> connections.
> More likely to cause confusion is the Tomcat message "increase the threads",
> while it might help more if it was "fine tune the threads" instead.  

I see, yes the default changed end of 2006 between 1.2.19 and 1.2.20.
Usually we don't change defaults, but the 10 was really to low.

> Rainer Jung-3 wrote:
>> but if the backend is stuck or too slow, this will not help 
>> and instead also trash the frontend.
> So perhaps.. upgrading from older JKs the default changed from 10
> connections to 250. With a lot of workers (for instance, 40) the total
> number of maximum threads went from 400 to 10000. I will have to fix this
> and check what happens.

Yes, if the notion of worker is an IIS worker and not an isapi plugin
worker. A plugin worker in the sense of a worker configuration item in is 1:1 with a connection pool, and a connection pool
doesn't create threads. It will grow at most as the lower of thread
number and configured pool size.

For iis workers see Mladen's response.

> Rainer Jung-3 wrote:
>> You should measure how many connections you need during peak hours 
>> without performance problems, and then add some percentage depending on 
>> your growth rate etc. Finally you need to make sure, that your web 
>> server itself uses at least as many threads, as you configured as the 
>> pool size.
> This has been measured already. Same as above, when the problem were too few
> connections, too many seemed not to be a problem. :-)
> I would suggest to add your above sentence right after "We recommend
> adjusting this value for IIS and the Sun Web Server" at
> and
> maybe also in
> (And maybe *strongly* recommend it )


> Rainer Jung-3 wrote:
>> For Apache with mod_jk we can automatically detect the number of threads 
>> and by default size our pool to the same number. For IIS you have to 
>> size the pool yourself (or live with the big default of 250).
> It seems we are dying with the big default. :-)
> I have read somewhere that the number of threads is not likely to cause
> these problems on modern multiple cpu with multiple cores servers. I wonder
> if there is some kind of formula to know what total should not be exceeded
> in this particular case, of if the good old document by Mladen Turk is still
> valid fixing this number to 2000
> (

I do think so, although I didn't actually test recently.



To start a new topic, e-mail:
To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message