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
