Re: BIO acceptorThreadCount
On 21/03/2013 00:13, igaz wrote: I was curious as to people's actual experience with setting a Connector's acceptorThreadCount while using the BIO http connection (the default) Frankly, I was unaware that java.net.ServerSockets were multi-thread safe (although interestingly the javadoc explicitly states that ServerSocketChannels are) Has anyone seen throughput increase with larger # of acceptorThreads? Did you set it == to # of hardware threads? It makes a marginal improvement if you increase it to 2 (assuming you have two+ cores). There is no improvement beyond 2. There is an underlying sync block for accepting new connections. Mark - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: BIO acceptorThreadCount
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Mark, On 3/21/13 5:49 AM, Mark Thomas wrote: On 21/03/2013 00:13, igaz wrote: I was curious as to people's actual experience with setting a Connector's acceptorThreadCount while using the BIO http connection (the default) Frankly, I was unaware that java.net.ServerSockets were multi-thread safe (although interestingly the javadoc explicitly states that ServerSocketChannels are) Has anyone seen throughput increase with larger # of acceptorThreads? Did you set it == to # of hardware threads? It makes a marginal improvement if you increase it to 2 (assuming you have two+ cores). There is no improvement beyond 2. There is an underlying sync block for accepting new connections. I've often wondered about that note in the documentation about the acceptorThreadCount. When you say there is an underlying sync block, is that the explanation for why many threads will not improve the situation, or just additional information? If there is a sync block, why will two threads improve things -- because the small amount of time dispatching a connection is still large compared to the time required to acquire the lock? These days, almost everyone has 2+ cores, even in development environments. Would it make sense to change Tomcat's default acceptorThreadCount to 2 if it is likely to improve performance, even if only slightly? We could even detect the number of processors before doing such a thing... Thanks, - -chris -BEGIN PGP SIGNATURE- Version: GnuPG/MacGPG2 v2.0.17 (Darwin) Comment: GPGTools - http://gpgtools.org Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBCAAGBQJRSwUpAAoJEBzwKT+lPKRY9eAP/iegkG5tkQscQG5wc+2kUnwO UyN5y3dKPFJyjfq2QX/3kVi18B3N1K7/HqYDq3b985TPmem+/VeQgzw8FIBZXy7o qDe2M5SOyqnnCzgNcfQZxhQnbgGYsk8eweUCBBJFQyIGIEji7dGs9emUizkr74mn 9z6YP1aaUboG7yUPX0Y/W53Hxl5llopBuBQGSotJhFk43ABY9cxAeL+JLmMYiBWO qaGwg8bT3Ixrkd9R9s5IZwCXDu2kA7MHKVvWoVAxVuauTR/2emXc/48BP7GV5o13 YH70ikgLpg/AZLX+c5MbYeTtV3Q4RhUPTOSqZZRs6w8BLfU1sfwjVQSPGNPtCUCa tE2aLAZGgCvnsDXFcp8mt+FjYZ5Zgvk2Ln3cXyTmBfaD6F0BXN3fDWlSzM2JrCXt 73WG2LtvyDKX+WhOcpBhT73rQj30rliDTEVuG1lF5BLur975bksIO9bQ2BECKLTX uS+2Yz8XTF/jk6wz23NTTl7DRPvHEz++fpBQJp04aYMTYObld4J6nz+PGlKAshqt lJhLTnawb2juAhuMYDz002HrQZQUp4Fsy1VDEXbU+xtfj/Rr3i/bWSlW8VXWxnxc dIItRfbSTYALOrLLUwQhOgvzeIbUQLT0KdnjFA22qGJs371GzOrHhGoVRAXiFA/X xCTPcshUF4TZEyxTUYtT =/XHi -END PGP SIGNATURE- - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: BIO acceptorThreadCount
On 21/03/2013 13:03, Christopher Schultz wrote: Mark, On 3/21/13 5:49 AM, Mark Thomas wrote: On 21/03/2013 00:13, igaz wrote: I was curious as to people's actual experience with setting a Connector's acceptorThreadCount while using the BIO http connection (the default) Frankly, I was unaware that java.net.ServerSockets were multi-thread safe (although interestingly the javadoc explicitly states that ServerSocketChannels are) Has anyone seen throughput increase with larger # of acceptorThreads? Did you set it == to # of hardware threads? It makes a marginal improvement if you increase it to 2 (assuming you have two+ cores). There is no improvement beyond 2. There is an underlying sync block for accepting new connections. I've often wondered about that note in the documentation about the acceptorThreadCount. When you say there is an underlying sync block, is that the explanation for why many threads will not improve the situation, or just additional information? Explanation. If there is a sync block, why will two threads improve things -- because the small amount of time dispatching a connection is still large compared to the time required to acquire the lock? Yes. The acceptor thread spends some time dispatching the request that a second thread can spend inside the lock getting the next connection. These days, almost everyone has 2+ cores, even in development environments. Would it make sense to change Tomcat's default acceptorThreadCount to 2 if it is likely to improve performance, even if only slightly? We could even detect the number of processors before doing such a thing... I thought Filip had done that for at least one of the connectors. If it doesn't apply to all, it should. Mark - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
