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

Robert G. Jakabosky bobby at sharedrealm.com
Wed Aug 29 23:06:33 CEST 2012


On Wednesday 29, Julie Anderson wrote:
> So questions remain:
> 
> 1) What does ZeroMQ do under the rood that justifies so many extra clock
> cycles? (I am really curious to know)

ZeroMQ is using background IO threads to do the sending/receiving.  So the 
extra latency is do to passing the messages between the application thread and 
the IO thread.


> 2) Do people agree that 11 microseconds are just too much?

No.  A simple IO event loop using epoll is fine for a IO (network) bound 
application, but if you need to do complex work (cpu bound) mixed with non-
blocking IO, then ZeroMQ can make it easy to scale.

Also try comparing the latency of Java NIO using TCP/UDP against ZeroMQ using 
the inproc transport using two threads in the same JVM instance.

With ZeroMQ it is easy to do thread to thread, process to process, and/or 
server to server communication all at the same time using the same interface.

Basically ZeroMQ has different use-case then a simple IO event loop.

-- 
Robert G. Jakabosky



More information about the zeromq-dev mailing list