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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
