[Date Prev][Date Next]
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
(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
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.
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
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.
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
-- Howard Chu
Chief Architect, Symas Corp. Director, Highland Sun
Symas: Premier OpenSource Development and Support