Re: kqueue for sockets on freebsd (non-polling)
On Wed, Jan 09, 2008 at 10:20:13AM -0800, Eric Brown <[EMAIL PROTECTED]> wrote: > wasn't always clear to me as to whether the concerns were about kqueue > or about the way libev uses kqueue. Hence my question. :) > > Assuming I go with libev (likely), I'm developing on leopard but my > target is freebsd. If there's some amount of testing you need, let me > know. Not really, by now, I know mostly what to expect. It was just my initial suprirse to see how broken kqueue really is, in practise, because nobody has seemed to try to use it as a replacement for poll/select in "normal" programs. > >What do you mean with "kqueue in non-polling mode"? afaik, kqueue only > >supports a polling mode, and this is what both libevent and libev use. > > I'm talking about kevent(..., const struct timespec *timeout). Since I > don't care about signals, fork events, etc. - all I care about is > sockets - I don't think I want a 0 timeout in the call to kevent(). I > see ev_set_io_collect_interval and I'm guessing this is what controls > that? > > So by polling, all I meant was use of kevent with a 0 timeout. I don't see why you want to rule out kevent with a zero timeout. The way to avoid a zero timeout is to call ev_set_timeout_collect_interval (_not_ io), because the timeout parameter is tied to the timer handling (when put this way its obvious :) I am, however, curious as why you'd want to avoid kevent calls with a zero timeout? Under normal operations, libev will not call libevent with a zero timeout, but if it does, its usually for good reasons (and then you cannot avoid it), and without understanding exactly what problem to solve, I would suggest against setting any of the collect intervals - they are very specific, advanced functions not normally necessary to achieve specific performance (they can improve efficiency, e.g. at powresaving, at the expense of latency, which should be a rare thing tor equire for a busy server). But then, if you need it, its there. Just think twice before using it without knowing exactly why you need it. > Thanks! I'm being told by a customer to use kqueue. At least with > libev I can easily switch to something else if it doesn't work out. Even without recompiling (and to some extent, also with libevent :). > BTW, I'm told I need to support 1000s of connections. But my suspicion > is that reality may be in the low 100s. On a fast server, do you have > any idea where the cross-over is between poll/select and kqueue Thats hard to say: select and poll on bsds are implemented differently, and usually are slower no matter what, so the break even point would be at or near 0 connections :) It all depends on how you use it, of course: if most of your connections are active, then select can be quite adequate, if most of your connections are idle (the more common case) then select will likely be rather bad even at a few dozen connections. And again, if you app spends seconds processing each conenction, then the slowdown caused by select will not be noticable, either. In general, I would *expect* kqueue to compare fabvourably in all cases against select, and certainly with a few hundred connections. > performance? I see your benchmarks, but I don't think they compare > different mechanisms. The libevent homepage has two graphs comparing different mechanisms. They are pretty adequate to show the basic different between select and another mechanism, but the break-even point depends on many external factors. In any case, if you want a second opinion on a problem, feel free to present your problem here (its usually easier than verifying a solution to an unknown problem), thats what the mailinglist is for, so don't hold back. -- The choice of a Deliantra, the free code+content MORPG -==- _GNU_ http://www.deliantra.net ==-- _ generation ---==---(_)__ __ __ Marc Lehmann --==---/ / _ \/ // /\ \/ / [EMAIL PROTECTED] -=/_/_//_/\_,_/ /_/\_\ ___ libev mailing list libev@lists.schmorp.de http://lists.schmorp.de/cgi-bin/mailman/listinfo/libev
Re: kqueue for sockets on freebsd (non-polling)
Hi Marc, On Jan 9, 2008, at 7:58 AM, Marc Lehmann wrote: > On Wed, Jan 09, 2008 at 01:20:35AM -0800, Eric Brown <[EMAIL PROTECTED] > > wrote: >> Anyway, I read a number of concerns about libev & kqueue. > > What concerns? libev supports kqueue just fine... It is kqueue that > is making > problems on most BSDs, though. There were a few comments in the libev docs and mailing list. It wasn't always clear to me as to whether the concerns were about kqueue or about the way libev uses kqueue. Hence my question. :) Assuming I go with libev (likely), I'm developing on leopard but my target is freebsd. If there's some amount of testing you need, let me know. >> Since all I care about are sockets, can I get libev to use kqueue >> in an >> efficient non-polling mode? Or am I better off looking at libevent or >> using kqueue directly? > > What do you mean with "kqueue in non-polling mode"? afaik, kqueue only > supports a polling mode, and this is what both libevent and libev use. I'm talking about kevent(..., const struct timespec *timeout). Since I don't care about signals, fork events, etc. - all I care about is sockets - I don't think I want a 0 timeout in the call to kevent(). I see ev_set_io_collect_interval and I'm guessing this is what controls that? So by polling, all I meant was use of kevent with a 0 timeout. >> Sorry, I'm new to libev and kqueue - more used to using select() >> directly or other higher level APIs. But libev looks really great. > > Thanks. While, of course, I think that libev has a lot of advantages > over > libevent (such as a more rational API (espeically when > multithreading) and > higher performance), libevent is certainly adequate to the job as > well. > > You should probably look at the libevent example program, and the > libev > documentation (which also has examples) and choose the one that > appeals most > to you. > > If you are only interested in sockets and simple timeouts, then both > libraries have the same feature set (although understanding how > timeouts > work in libevent can be difficult, it certainly was for me). > > libevent example: http://monkey.org/~provos/libevent/event-test.c > libevent docs: http://monkey.org/~provos/libevent/doxygen/ > libev docs: http://pod.tst.eu/http://cvs.schmorp.de/libev/ev.pod > > If you insist on using kqueue everywhere (watch out, its buggy on > most os > x releases even for sockets), then this will give you an event loop > using > kqueue in libev, whenever kqueue is available: > > #include > > struct ev_loop *loop = > ev_loop_new ( > ev_recommended_backends () | EVBACKEND_KQUEUE > ); > > assert ((loop, "libev initialisation failed")); Thanks! I'm being told by a customer to use kqueue. At least with libev I can easily switch to something else if it doesn't work out. BTW, I'm told I need to support 1000s of connections. But my suspicion is that reality may be in the low 100s. On a fast server, do you have any idea where the cross-over is between poll/select and kqueue performance? I see your benchmarks, but I don't think they compare different mechanisms. Cheers, Eric ___ libev mailing list libev@lists.schmorp.de http://lists.schmorp.de/cgi-bin/mailman/listinfo/libev
Re: kqueue for sockets on freebsd (non-polling)
On Wed, Jan 09, 2008 at 01:20:35AM -0800, Eric Brown <[EMAIL PROTECTED]> wrote: > Anyway, I read a number of concerns about libev & kqueue. What concerns? libev supports kqueue just fine... It is kqueue that is making problems on most BSDs, though. > Since all I care about are sockets, can I get libev to use kqueue in an > efficient non-polling mode? Or am I better off looking at libevent or > using kqueue directly? What do you mean with "kqueue in non-polling mode"? afaik, kqueue only supports a polling mode, and this is what both libevent and libev use. > Sorry, I'm new to libev and kqueue - more used to using select() > directly or other higher level APIs. But libev looks really great. Thanks. While, of course, I think that libev has a lot of advantages over libevent (such as a more rational API (espeically when multithreading) and higher performance), libevent is certainly adequate to the job as well. You should probably look at the libevent example program, and the libev documentation (which also has examples) and choose the one that appeals most to you. If you are only interested in sockets and simple timeouts, then both libraries have the same feature set (although understanding how timeouts work in libevent can be difficult, it certainly was for me). libevent example: http://monkey.org/~provos/libevent/event-test.c libevent docs: http://monkey.org/~provos/libevent/doxygen/ libev docs: http://pod.tst.eu/http://cvs.schmorp.de/libev/ev.pod If you insist on using kqueue everywhere (watch out, its buggy on most os x releases even for sockets), then this will give you an event loop using kqueue in libev, whenever kqueue is available: #include struct ev_loop *loop = ev_loop_new ( ev_recommended_backends () | EVBACKEND_KQUEUE ); assert ((loop, "libev initialisation failed")); -- The choice of a Deliantra, the free code+content MORPG -==- _GNU_ http://www.deliantra.net ==-- _ generation ---==---(_)__ __ __ Marc Lehmann --==---/ / _ \/ // /\ \/ / [EMAIL PROTECTED] -=/_/_//_/\_,_/ /_/\_\ ___ libev mailing list libev@lists.schmorp.de http://lists.schmorp.de/cgi-bin/mailman/listinfo/libev
kqueue for sockets on freebsd (non-polling)
Hi, I'm trying to write a simple, fast server for freebsd that can handle thousands of open connections - all sockets. Tentatively one loop per thread / one thread per core (not sure how/if I'll get thread affinity). Anyway, I read a number of concerns about libev & kqueue. Since all I care about are sockets, can I get libev to use kqueue in an efficient non-polling mode? Or am I better off looking at libevent or using kqueue directly? Sorry, I'm new to libev and kqueue - more used to using select() directly or other higher level APIs. But libev looks really great. Cheers, Eric ___ libev mailing list libev@lists.schmorp.de http://lists.schmorp.de/cgi-bin/mailman/listinfo/libev
