Re: [Boost-users] [asio] io_service threadpool performance

Subject: Re: [Boost-users] [asio] io_service threadpool performance
From: Oliver Seiler (oseiler_at_[hidden])
Date: 2009-03-18 13:53:26

On Tue, Mar 17, 2009 at 2:44 PM, Rutger ter Borg <rutger_at_[hidden]> wrote:
> [...]
> You're saying that it is taken for granted that ASIO is bad at handling a
> great deal of (small) tasks? Taken that for true, then asio also must be
> bad at handling a large number of small network messages. I.e., I shouldn't
> try handling all data of a couple of NICs with ASIO, at least not using a
> threadpool setup?

As I said, perhaps someone more familiar with it could comment; that
assessment was from trying out the sample code, playing around with
it, and playing around with TBB.

There appears the be a 2-lock queue implementation for the
handler_queue that is used by the io_service for dispatching handlers;
I can't really tell if it is being used or not, or if it has to be
enabled manually. This might help performance in the sample.

> I was under the impression that ASIO is a high-performance asynchronous
> event and IO library, and as such, is good at everything it does... Perhaps
> a lock-free task-queue would change things for the better.

You should maybe develop a more realistic test. The sample code was
testing the parallelism of the dispatching code in a sort of
worst-case (trivial CPU-bound operation that probably doesn't even
need to access any memory), and seemingly it doesn't scale well to
multi-core hardware. But unless you're doing something just as trivial
in the handlers as you are in the sample, so what?

Having written similar things (i.e., asynchronous message-passing
to/from network sockets), I've never really found much use,
performance-wise, for any more than one thread for dealing with
select/poll/epoll/etc on a pool of sockets, compared to the overhead
of computation/IO associated with actually doing something with what
gets read off the wire.

Anyway, I'm not trying to dissuade you from using ASIO, nor trying to
imply that it isn't high-performance (high-performance compared to
what, for example). I have no idea what you're intended use is. I do
notice that the ASIO documentation doesn't really focus on use beyond
device IO, and it seems perfectly suitable to that. I would tend to
prefer using something like TBB or a simple thread-pool implementation
for dispatching the computational work, rather than doing it in ASIO,
based solely on that documentation and having now looked a bit at the
implementation.

> Thanks for pointing out TBB, I'll take a look -- however I'm primarily
> interested in taking message handling/event handling to the max.

Depends on what happens in the event handling; if you're doing
something to disk or a database, I'd suggest you not worry about this
aspect of it. If you're doing some sort of computation, bundle up more
work per message.