I think if we switch to fine-grained locking and away from large-grained try-locks we could deal with the latency issue and get the most out of the accept thread since we could synchronise between the accept and net threads faster. This is likely to be easier with a simplified codebase as well.
On Mon, Jan 23, 2012 at 10:35 AM, Leif Hedstrom <l...@godaddy.com> wrote: > 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 > >
