tomcat-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Rainer Jung <rainer.j...@kippdata.de>
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
workers.properties 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
> http://tomcat.apache.org/connectors-doc/generic_howto/timeouts.html and
> maybe also in http://tomcat.apache.org/connectors-doc/reference/workers.html
> (And maybe *strongly* recommend it )

Done.

> 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
> (http://people.apache.org/~mturk/docs/article/ftwai.html)

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

Regards,

Rainer

---------------------------------------------------------------------
To start a new topic, e-mail: users@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