|
Home > Archive > Unix Programming > November 2007 > High-performance server: epoll or a thread pool?
You are viewing an archived Text-only version of the thread.
To view this thread in it's original format and/or if you want to reply to
this thread please [click here]
| Author |
High-performance server: epoll or a thread pool?
|
|
| Arkadiy 2007-11-29, 1:30 pm |
| Hi all,
I need to build a performance-critical TCP server, and trying to make
a decision of whether to use IO multiplexing (with epoll) or just
dispatch requests to one of worker threads (from the thread pool),
each worker doing synchronous IO and processing. We will probably
have a limited number of connections reused for multiple requests.
My initial test show that epoll-based system is about 30% faster (and
utilizes processor much better), but I suspect that when comparing
performance of such systems, a lot needs to be taken into account --
network bandwidth, the number of processors, usage pattern, IO to
processing ratio, worker threads, etc.
(for the test I read 50 byte request, perform search in std::map 50
times, and send 250 byte response. I have two processors)
Do you think it is possible to say that this test data reflect the
reality more or less accurate, and the epoll-based server would be
generally more efficient?
Thanks in advance,
Arkadiy
| |
| Rainer Weikusat 2007-11-29, 1:30 pm |
| Arkadiy <vertleyb@gmail.com> writes:
> I need to build a performance-critical TCP server, and trying to make
> a decision of whether to use IO multiplexing (with epoll) or just
> dispatch requests to one of worker threads (from the thread pool),
> each worker doing synchronous IO and processing. We will probably
> have a limited number of connections reused for multiple requests.
>
> My initial test show that epoll-based system is about 30% faster (and
> utilizes processor much better), but I suspect that when comparing
> performance of such systems, a lot needs to be taken into account --
> network bandwidth, the number of processors, usage pattern, IO to
> processing ratio, worker threads, etc.
>
> (for the test I read 50 byte request, perform search in std::map 50
> times, and send 250 byte response. I have two processors)
>
> Do you think it is possible to say that this test data reflect the
> reality more or less accurate, and the epoll-based server would be
> generally more efficient?
It will generally be more efficient to distribute task among about as
many threads as one has processor to run them using some
multiplexeing-scheme than to have signficantly more runnable threads
than processor, reason: context-switching overhead.
| |
| Chris Friesen 2007-11-29, 1:30 pm |
| Arkadiy wrote:
> Hi all,
>
> I need to build a performance-critical TCP server, and trying to make
> a decision of whether to use IO multiplexing (with epoll) or just
> dispatch requests to one of worker threads (from the thread pool),
> each worker doing synchronous IO and processing. We will probably
> have a limited number of connections reused for multiple requests.
I suspect a hybrid approach would be best. Use one thread per available
cpu core, with epoll to track readable sockets.
Chris
| |
| Rick Jones 2007-11-29, 7:21 pm |
| Arkadiy <vertleyb@gmail.com> wrote:
> Do you think it is possible to say that this test data reflect the
> reality more or less accurate, and the epoll-based server would be
> generally more efficient?
In broad terms yes because your epoll-based code probably has a much
lower "context switch" overhead than a thread switch would.
If you can get all the work done you need to get done with the
services of a single core, then I prefer the epoll-esque
approach. Now, if in servicing one client, your epoll-esque code could
block for a while that might not be good and would be an indication of
thread-per-something.
If you need the services of more than one core, then as pointed-out,
something more hybrid would be good - either thread or if you don't
need as tight a coupling, process per core.
rick jones
--
a wide gulf separates "what if" from "if only"
these opinions are mine, all mine; HP might not want them anyway... 
feel free to post, OR email to rick.jones2 in hp.com but NOT BOTH...
|
|
|
|
|