On 1/23/12 11:21 AM, Theo Schlossnagle wrote:
On Linux, FreeBSD and Solaris (at least), even with the most recent nonblocking kernel facilities, it is still faster to accept new TCP connections in a blocking fashion via thread pool. FWIW.
That definitely was the case when we worked on Accept threads a while ago (a few years ago), I clearly remember it making a noticeable difference with the old code base. However, today, it seems to introduce more latency, compared to doing non-blocking accept() on all net-threads. I haven't spent a whole lot of time investigating why, but it certainly seems that now the dedicated (blocking) accept threads is "worse". It can do more accept's / second, but at a higher latency.
This could quite possibly be a problem in our code, since with accept threads enabled, the session has to be migrated between threads, so perhaps we're doing something inefficient there (or something that requires a scheduling retry etc. due to lock contention).
-- leif
