[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://127.0.0.1.
>    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. :)))

-Julie



> _______________________________________________
> 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