-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Vishwajit,
On 5/18/2009 2:01 PM, Pantvaidya, Vishwajit wrote: > Yes, sure - we will upgrade at some point of > time. But since upgrading all our servers will be some work, that may > not happen right away. Upgrading mod_jk is the least painful of all of these, and the most likely to affect you. > Here are figures from 3 of the servers which > have not yet run out of threads (so the thread count does not add up > to 200). I have taken these late at night when no users are present, > so I was expecting all threads to be Waiting for tomcat thread-pool. > > 1. Total TP-Processor threads 48, Waiting 46, Runnable 2 > 2. Total TP-Processor threads 40, Waiting 29, Runnable 11 > 3. Total TP-Processor threads 120, Waiting 7, Runnable 113 Are you sure you aren't seeing any traffic, even that late at night? What if you watch the access logs? Are there requests actively being serviced? > Do you think this could be because of the > application? I was under the impression that there is some tomcat > config parameter that controls this - which was set to 4. No, Tomcat uses precisely 1 thread to handle each incoming HTTP request. If keepalives are used, multiple requests may be handled by the same thread before it is returned to the pool, or different threads may be used to serve different requests from the single connection, but in either case, no more than 1 thread will be used to service a single HTTP request. >>> My workers config is: >>> >>> Worker...type=ajp13 >>> Worker...cachesize=10 >> Are you using the prefork MPM? If so, cachesize should be /1/. > > [Pantvaidya, Vishwajit] Could you please elaborate. What is the > prefork MPM? The MPM is the concurrency strategy employed by Apache httpd. Either you are using the "prefork MPM" which starts multiple httpd processes to handle requests, or you are using the "worker MPM" which starts multiple threads to handle requests. Actually, mod_jk should be able to auto-detect the appropriate cachesize (called connection_pool_size, now), so you shouldn't have to set this. >>> Worker...cache_timeout=600 Worker...socket_keepalive=1 >>> Worker...recycle_timeout=300 >> Are these timeouts necessary? Why not simply let the connections >> stay alive all the time? >> > [Pantvaidya, Vishwajit] Sure we could. But for any production change, > I would have to offer a good enough reason. What was the "good enough reason" to set those timeouts in the first place? >>> Earlier posts related to this issue on the list seem to >>> recommend tweaking: - several timeouts - JkOptions +DisableReuse >> This will require that every incoming HTTP connection opens up a >> new ajp13 connection to Tomcat. Your performance will totally suck >> if you enable this. But if it's the only way for you to get your >> application working properly, then I guess you'll have to do it. I >> suspect you /will not/ have to enable +DisableReuse. >> > [Pantvaidya, Vishwajit] I was seeing earlier posts on this list > mention some disagreement on the performance impact of setting > +DisableReuse. Otherwise I would not even think of this. +DisableReuse will, without a doubt, decrease your performance. - -chris -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAkoRufgACgkQ9CaO5/Lv0PBGHwCfaOGjjv8A1wOAO0CrBKiMbVhM 9MEAoKD8QUbxfqd4h/8YcppkKAt2J1qM =+kJC -----END PGP SIGNATURE----- --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
