-----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

Reply via email to