Through some trials found that its not enough to increase the Executors thread count(maxThreads for Executor element) but also need to increase the Connectors thread count(maxThreads for Connector element). This behavior is not actually clearly captured in tomcat documentation says
"A reference to the name in an Executor element. If this attribute is set, and the named executor exists, the connector will use the executor, and all the other thread attributes will be ignored. Note that if a shared executor is not specified for a connector then the connector will use a private, internal executor to provide the thread pool." "all the other thread attributes will be ignored" makes impression that its enough to increase the Executor thread count. As executor is a shared thread pool and connector is using that but what I seen is Referencing the Executor in Connector element and setting maxThreads for Executor is not enough. If we do that tomcat creates no. of threads as per maxThread configuration of Executor but not all threads are actually used for request processing. Even if we put more load the activeCount will never go above 200 that is default maxThreads value of Connector. To get threads more than 200 we have to additionally set the maxThread attribute for Connectors element as well. (irrespective of Executor reference) When I explicitly set maxThreads for Connectors activeCount actually went UP to the maxThreads limit. Now I'm able to reach activeCounts beyond 250 see attachment. On Thursday, January 23, 2014 8:45 PM, Christopher Schultz <ch...@christopherschultz.net> wrote: -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 akshay, On 1/23/14, 9:07 AM, akshay hiremath wrote: > We have this HP load runner running a load of requests on this > system. We don't see request rejected by Tomcat but if I monitor > the activeCount attribute of Mbean > "Catalina:type=Executor,name=tomcatThreadPool" over the period of > test why the activeCount is not going above 200. if I continuously > track activeCount and currentThreadsBusy of MBean > "Catalina:type=ThreadPool,name="http-bio-8080"" I see the graph > reahes 200 and flat lines there. Please find monitored graph > attached during one of the tests. See time frm start of graph to > the 13:30 when test ended. ignore the in between part and rest > graph that is of another ongoing test. Attachments are stripped from the list. Find another way to express your thoughts. Is it possible that you are simply not generating enough load? If Tomcat is responding to all of your requests (e.g. none of them are failing to connect, failing to respond, or responding very slowly -- as if queued) than it sounds like your Tomcat instance is handling all the load you are throwing at it. - -chris > On Thursday, January 23, 2014 7:06 PM, Mark Thomas > <ma...@apache.org> wrote: On 23/01/2014 13:30, akshay hiremath > wrote: > >> Why tomcat is not able to have more than 200 active Threads >> (parallel threads) processng my requests? > > > It can. The issue is that the combination of the requests you are > making (which you fail to describe), your load testing framework > (which you fail to describe) and the scheduling in the CPUs of your > hardware (which you also fail to describe) mean that the chances of > there actually being 300 concurrent requests for Tomcat to process > is pretty much zero. > > Mark > > > --------------------------------------------------------------------- > > To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org > <mailto:users-unsubscr...@tomcat.apache.org> For additional > commands, e-mail: users-h...@tomcat.apache.org > <mailto:users-h...@tomcat.apache.org> > > > > > > > > --------------------------------------------------------------------- > > To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org > For additional commands, e-mail: users-h...@tomcat.apache.org > -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 Comment: GPGTools - http://gpgtools.org Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBCAAGBQJS4TH3AAoJEBzwKT+lPKRY1vQP/01g9bL731iYBYV9MQtDhLMJ LeBXfV2996qnpX2VftnltPGXq2V9/l93tjRMiDxrcaGIrdzebkzv+PegRdhIxto1 JeIJh9xBFKd+J/aWTmzDYLzE9/eGoGRW+R+G3MuqqBs3KSXaNbEDHtdB/5zzQ0Bj Ht7iWTvPyEkp3JeKBo/FM/nZG2cnBNwC+kNWkdzlOqPIWUVOPmbqQky2qkM86s+d 65trfkDDSkez1ws2bZJ42TbW3IR9Qv1H/YlMzMmr2BJpGUnTAIKwu0l+bD+kH8pT QQo7anuTpuygwsE30zO3FcgkwzTuPcccHTh0G1XvzCYFJJ+tnAa4h+0Z6GAu7q6E 5ltIyHZjp4KJoLulNFQfqlItjabi6XIUwwQk/Ob4pRpgfsORIwapusY1vFThwhJv m3M0fVgWmxCHc41ed+mMhUPewXqqv0iaXKj4oxuW9GSPfdlQ7wCECwcIR11K39aU Ff9dbEEFuT7yvKgQy589dsSycgydCONTS+4b/25stwR1VgxA2MlvhcF8LBNN3o8L kPefjrOQVGLAuwrSgBiAVsD9dNDis5UhQ0sdGUKoLSuI3HSy1KMANVUWjYmig4bP fUmhGlKiM9CknxUpDK/rdAGWUOQU06rXeWVitQ/2p42UQibtAhXuM+1ymw/v4zou SBh0nxrR6K0AVV8KhomP =TIpT -----END PGP SIGNATURE----- --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
--------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
