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

Julie Anderson julie.anderson.uk at gmail.com
Wed Aug 29 23:46:09 CEST 2012

See my comments below:

On Wed, Aug 29, 2012 at 4:06 PM, Robert G. Jakabosky
<bobby at sharedrealm.com>wrote:

> 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.
This kind of thread architecture sucks for latency sensitive applications.
That's why non-blocking I/O exists. That's my humble opinion and the
numbers support it.

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

Totally agree, but that has nothing to do with a financial application.
Financial applications do not need to do complex CPU bound analysis like a
image processing application would need. Financial application only cares
about LATENCY and network I/O.

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

What is the problem with inproc? Just use a method call in the same JVM or
shared memory for different JVMs. If you want inter-thread communication
there are blazing-fast solutions in Java for that too. For example, I would
be surprised if ZeroMQ can come close to Disruptor for inter-thread

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

This generic API is cool, but it is solving a problem financial systems do
not have and creating a bigger problem by adding latency.

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

I thought ZeroMQ flagship customers were financial institutions. Then maybe
I was wrong.

> --
> Robert G. Jakabosky
> _______________________________________________
> 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/6319651a/attachment.htm>

More information about the zeromq-dev mailing list