You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@tomcat.apache.org by igaz <th...@nomagicsoftware.com> on 2013/03/21 01:13:00 UTC

BIO acceptorThreadCount

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?  



--
View this message in context: http://tomcat.10.n6.nabble.com/BIO-acceptorThreadCount-tp4996539.html
Sent from the Tomcat - User mailing list archive at Nabble.com.

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org


Re: BIO acceptorThreadCount

Posted by Mark Thomas <ma...@apache.org>.
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-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org


Re: BIO acceptorThreadCount

Posted by Christopher Schultz <ch...@christopherschultz.net>.
-----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-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org


Re: BIO acceptorThreadCount

Posted by Mark Thomas <ma...@apache.org>.
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-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org