[Date Prev][Date Next] [Chronological] [Thread] [Top]

Re: (ITS#3665) Multi-Listener Thread Support

David Boreham wrote:

Right, that's what I was trying to say : unless you get rid of the context switch
(at least in the common cases), then it's a waste of time (because its the context
switch that kills performance in this area. You said it would make more sense
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 switch.
What would really help would be to avoid the context switch. 

OK, now I understand what you were saying, thanks.

Another thing to consider is the relative
cost to the I/O and operation decode and context switch vs. the cost to perform
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 searches however
is _does_ represent a significant proportion of the overall code path.

Pretty much. Actually it seems to me that writing the response is a major portion of execution time, but that's somewhat unavoidable.

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 +).

Yes. That was my point; the performance aspect of the patch is negligible, only the resilience issue is worth considering. With my suggestion we get the added resilience without making the event loop more complicated.

--
 -- Howard Chu
 Chief Architect, Symas Corp.       Director, Highland Sun
 http://www.symas.com               http://highlandsun.com/hyc
 Symas: Premier OpenSource Development and Support