On 21 Mar 2014 at 9:54, Donald Alan wrote:
When the client is running against synchronous server it is able to receive around 700K msgs/sec but when it is running against asynchronous server the performance is dropped to around 100K-120K msgs/sec. I know that one should use asynchronous IO for scalability when we have more number of clients and in the above case as I'm using only a single client, the obvious advantage of asynchronous IO is not evident. But the question is, is asynchronous IO expected to effect the performance so badly for a single client case or am I missing some obvious best practices to follow with asynchronous IO? Is the significant drop in the performance is because of the thread switch between ioservice thread (which is main thread in the above case) and connection thread?
Linux isn't capable of asynchronous i/o [1], so of course directly calling synchronous kernel APIs will be faster than using threads to multiplex kernel APIs. I think most of your disparity though is that you are doing at least two (and probably more) syscalls per message for the async case as ASIO must do a poll/select per message. I'd very interested to see your results on an OS which does implement async i/o - Windows is the easiest. Anyway, I really wouldn't worry about ASIO performance. ASIO can exceed 3m threaded dispatches per second on a quad core Intel. Even AFIO, which extends ASIO and uses lots of "slow" futures, breaks past 1.5m dispatches/sec. [1]: Linux can do non-blocking socket i/o, but non-blocking is *not* asynchronous i/o. Linux can do a limited amount of async file i/o using a special syscall not used by any of the libc implementations of POSIX routines. FreeBSD can do async i/o, but ASIO isn't wired up for it. Niall -- Currently unemployed and looking for work in Ireland. Work Portfolio: http://careers.stackoverflow.com/nialldouglas/