Vjekoslav Brajkovic wrote:

...

posting 10 M jobs to the io_service, and starting N threads at io_service::run after that. Timings below are measured on an 8-core machine, I would expect

I suppose you are the one instantiating the connection.

This is apart from any connection, it's measuring io_service as a pure job dispatcher.

I had the same exact symptoms a week ago... not sure if this is the same problem. However instead of using threadpool, I was using thread_group(). The pseudo code looked something like this:

Interesting -- what would be the expected performance difference between a thread group and a pool of threads?

I haven't had time to investigate what was causing the issue.

Do you know if all of io_service's jobs are dispatched through a platform-specific dispatcher, e.g., epoll? Thanks, Rutger

Someone more familiar with the implementation could comment, but just poking around through the implementation it appears there is one queue of handlers that will get shared by all threads; right there I think there'll be a lot of lock contention between threads on the single queue.

What if you use io_service-per-cpu approach? How does it affect the performance?

On Tue, Mar 17, 2009 at 2:44 PM, Rutger ter Borg 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.