I'd just made some tests with a set/get/ client application that uses that database.
I moved the sleep to inside a boost:.asio callback and then called event_base_loop(_event_base, EVLOOP_NONBLOCK) from that callback. with a timer of 1 ms my test performed 8k transactions /s at <1% load with a timer of 0 ms my test performed 40k transactions /s at ~100% load (of one core) - this is of course a busy loop. for my use case 8K transactions/s / core is ok (for now) - even if it's a ugly patch.... In real life, incoming transactions from the serverside will actually help the client lib performance since the event loop is called more often. Thanks for the help. 2014-11-20 14:33 GMT+01:00 Azat Khuzhin <[email protected]>: > On Thu, Nov 20, 2014 at 04:21:06PM +0300, Azat Khuzhin wrote: > > On Thu, Nov 20, 2014 at 01:27:14PM +0100, svante karlsson wrote: > > > Thanks, > > > > > > First of all I made a typo in my own comments - the return parameter > from > > > boost::asio::poll is the number of handlers it did run (not one). > > > > You are right. > > > > I've just checked io_service.poll(): > > $ strace -eepoll_wait ./a.out > > pre poll > > epoll_wait(4, {{EPOLLIN, {u32=11063784, u64=11063784}}, {EPOLLIN, > {u32=11063888, u64=11063888}}, {EPOLLIN, {u32=11063796, u64=11063796}}}, > 128, 0) = 3 > > post poll > > > > timeout=0 === no blocking. > > > > > According to spec it runs handlers that are ready to run, without > blocking > > > and I'm pretty sure it does what it says (Not blocking) > > > > > > Second, it's a bit worrying (for me at least) that the libevent > equivalent > > > call does indeed block - Do you have any hints on when it's actually > > > blocking? > > > >(event_base_loop(_event_base, EVLOOP_NONBLOCK); > > > > I was wrong, sorry, it will not block with EVLOOP_NONBLOCK. > > > > > > > > Third, I also agrees on "and personally I don't think that it is sane > to > > > use two event loops in one application", BUT either I rewrite an > existing > > > (proprietary) proxy based on asio or an existing db client library > > > (aerospike db) based on libevent. > > > > > > I'm thinking I might get away with handling the server code from asio > and > > > make polling calls to libevent queue in asio callbacks on events - both > > > timer and io related ones but I'm looking for a cleaner solution. > > Anyway, to make it work without sleep(), you need fd of event base (for > instance fd that returns epoll_create()). > > And neither libevent [1] nor asio [2] exports it. > > But even if you will patch both, and you will be able to get this fd, > than you need some logic for other mechanisms like select(), so I guess > appropriate sleep() will be better. > > [1] https://github.com/libevent/libevent/blob/master/epoll.C > [2] > http://www.boost.org/doc/libs/1_38_0/boost/asio/detail/epoll_reactor.hpp > > > > > > > I've done the same for a libcurl based client in the past and it was > > > possible to get to the sockets before libcurl actually waited for io. > > > > libcurl is something very different, it is not _aio_ library, but AFAIR > it > > allow to multiplexing stuff using custom event loop (i.e. you could get > > internal fd), that's why you could do this using libcurl I suppose. > *********************************************************************** > To unsubscribe, send an e-mail to [email protected] with > unsubscribe libevent-users in the body. >
