On 09/05/2019 12:45, Rémy Maucherat wrote: > Hi, > > A long time ago (in this galaxy, not another one), Tomcat has added the > capability to have multiple accept threads. I have no idea what test > revealed that Tomcat was somehow not accepting sockets fast enough, and > maybe it could be the case in crazy microbenchmarks, but this is not going > to happen in the real world. If the server is too busy accepting, then what > comes after the accept (SSL handshake maybe) is much worse and refusing > sockets may be the most sensible behavior. Having multiple accept threads > is also now a known antipattern. > So I am proposing to hardcode acceptorThreadCount to 1 for all connectors. > > Same for polling basically. Polling occurs once a socket waits for data or > backlogs for about an eternity (in CPU time), so a single polling thread is > more than enough to handle this in a responsive enough way (BTW, I am > interested in current data that demonstrates a responsiveness benefit). > Earlier in the past, with APR and plain old select (and Windows !!), it was > probably way more justified to allow having multiple threads. > So I am also proposing to hardcode pollerThreadCount to 1 for NIO. I will > leave the feature in for APR, just in case. > > Note: NIO 2 works properly, yet uses no dedicated accept thread (accept is > now an async task that restarts itself once done), and internally has one > internal thread for polling and one internal thread for timeouts. So ... > > Comments ?
accept() is effectively synchronized at the OS level. I recall doing some testing on this and there was a small gain in throughput when testing on localhost without keep-alive if I used two accept threads. Essentially, one thread was accepting the next connection while the other was handing a connection off to a processing thread. There was no benefit for more than 2 accept threads. I also had to keep the total number of concurrent requests to ~number of available cores. I can think of no real world scenario where Tomcat would be accepting new connections fast enough with a low enough concurrency level for 2 accept threads be useful. +1 to hard-coding to a single acceptor thread and removing the plumbing that supports more than that. Mark --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
