[Date Prev][Date Next]
Re: (ITS#3665) Multi-Listener Thread Support
On average the number of context switches with my suggested approach
will be the same. Consider a single CPU system with two listener
threads, using the provided patch. At most one of the listener threads
can be active; if an event arrives for the queued thread, you get a
switch anyway. The relevant listener then reads the socket, parses the
data, and pushes the operation into the thread pool - you get a second
context switch here. If neither of the listener threads was active
(because an operation thread was active) then you get two context
switches regardless of the number of listener threads, and on a busy
server this is the most likely sequence of events.
Right, that's what I was trying to say : unless you get rid of the
(at least in the common cases), then it's a waste of time (because its
switch that kills performance in this area. You said it would make more
to hand off the operation at an earlier phase in its life to the pool
thread : I'm
saying that this doesn't help much because you still have the context
What would really help would be to avoid the context switch.
Another thing to consider is the relative
cost to the I/O and operation decode and context switch vs. the cost to
the rest of the operation processing. If the I/O and stuff is only 10%
of the total
effort then optimizing it won't help much overall. IME for simple
is _does_ represent a significant proportion of the overall code path.
On the other hand, if we keep just one listener thread, which invokes
another thread to do the reading and parsing, we prevent the current
event loop code from getting even more complicated than it already is.
All of the data structures involved in dispatching the operation are
already mutex protected so making the reader/parser multithreaded
doesn't impose any new overhead.
Agreed. It isn't worth adding significant complexity unless the
performance benefit is
significant (e.g. 2X +).