So, are there any benchmark tests that can be used to quantify the overhead of zmq_poll? It seems like this question keeps coming up, and it would certainly be nice to have some real numbers (and the code used to generate them).
Having said that, there are several mechanisms that zmq_poll can use, and there are apparently significant performance differences between them. My understanding of the conventional wisdom is that epoll is preferable to poll, which is preferable to select — but I don’t have any data to back that up. In any event, you can examine the output of the libzmq build to see which mechanism is being used: -- Looking for kqueue -- Looking for kqueue - not found -- Looking for epoll_create -- Looking for epoll_create - found -- Looking for epoll_create1 -- Looking for epoll_create1 - found -- Detected epoll polling method I’ve found one (very old!) post that discusses these differences: https://cs.uwaterloo.ca/~brecht/servers/epoll/. If anyone can suggest additional sources, please do. > On Apr 11, 2018, at 1:46 PM, Luca Boccassi <luca.bocca...@gmail.com> wrote: > > On Wed, 2018-04-11 at 18:47 +0200, Francesco wrote: >> Hi all, >> >> I'm using zmq_poller_wait_all() API in one of my threads because I >> need to >> poll over 2 ZMQ sockets. >> I'm receiving a lot of traffic on both these sockets. >> I think the performance of my software is bad and that may be due >> IMHO to >> the huge amount of poll() syscalls that my thread does... I think the >> overhead of doing the system call is what is killing me... >> >> so my question is: when zmq_poller_wait_all() polls zmq FDs it is >> actually >> polling the real socket FD or rather some ZMQ internal structure? >> If the latter is true, do I have a way to poll more than 1 zmq socket >> without doing a system call? >> >> >> THanks, >> Francesco > > I'm not familiar with the zmq_poller API so someone else might help - > in general, a common optimisation is to drain the socket using non- > blocking receives when poll wakes up (taking care of using heuristic to > avoid starving the other sockets), so that you can process multiple > messages per poll > > -- > Kind regards, > Luca Boccassi_______________________________________________ > zeromq-dev mailing list > zeromq-dev@lists.zeromq.org <mailto:zeromq-dev@lists.zeromq.org> > https://lists.zeromq.org/mailman/listinfo/zeromq-dev > <https://lists.zeromq.org/mailman/listinfo/zeromq-dev>
_______________________________________________ zeromq-dev mailing list zeromq-dev@lists.zeromq.org https://lists.zeromq.org/mailman/listinfo/zeromq-dev
