[zeromq-dev] Too much ZeroMQ overhead versus plain TCP Java NIO Epoll (with measurements)

Julie Anderson julie.anderson.uk at gmail.com
Thu Aug 30 04:35:21 CEST 2012

See my comments below:

> They appear to
> be single threaded synchronous tests which seems very unlike the kinds
> of applications being discussed (esp. if you're using NIO). More
> realistic is a network connection getting slammed with lots of
> concurrent sends and recvs....which is where lots of mistakes can be
> made if you roll your own.
That's the point of NIO, which attracted me from the very beginning. Of
course it is not the solution for everything but for fast clients you can
SERIALIZE them inside a SINGLE thread so all reads and writes from all of
them are non-blocking and thread-safe. This is not just faster (debatable,
but specifically for fast and not too many clients) but most importantly
easier to code, optimize and keep it clean/bug free. Anyone who has done
serious multithreading programming in C or even Java knows it is not easy
to get it right and context-switches + blocking is the root of all latency
and bugs.

> As a purely academic discussion, though, I've uploaded raw C socket
> versions of a client and server that can be used to mimic local_lat and
> remote_lat -- at least for TCP sockets. On my MacBook, I get ~18
> microseconds per 40 byte packet across a test of 1000000 packets on
> local loopback. This is indeed about half of what I get with
> local_lat/remote_lat on tcp://
>    http://pastebin.com/4SSKbAgx   (echoloopcli.c)
>    http://pastebin.com/rkc6itTg  (echoloopsrv.c)
> There's probably some amount of slop/unfairness in there since I cut a
> lot of corners, so if folks want to pursue the comparison further, I'm
> more than willing to bring it closer to apples-to-apples.

Very awesome!!! Are 18 micros the round-trip time or one-way time? Are you
waiting to send the next packet ONLY after you get the ack from the
previous one sent? Sorry but C looks like japanese to me. :)))


> _______________________________________________
> zeromq-dev mailing list
> zeromq-dev at lists.zeromq.org
> http://lists.zeromq.org/mailman/listinfo/zeromq-dev
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.zeromq.org/pipermail/zeromq-dev/attachments/20120829/4ab885e2/attachment.htm>

More information about the zeromq-dev mailing list