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

Steven McCoy steven.mccoy at miru.hk
Thu Aug 30 01:12:17 CEST 2012

On 29 August 2012 17:46, Julie Anderson <julie.anderson.uk at gmail.com> wrote:

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

Non-blocking IO is a legacy from early structured programming, it just so
happens it fits well into a pro-actor model for IOCP performance.  Many
people prefer to develop code using the reactor model and 0mq fits well

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

That's not a financial application, that's an automated trading
application.  99.9% of financial applications do not remotely care about
latency, your sweeping generalisation just wiped out domains such as hedge
fund analytics and news.

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

This is relying on pro-actor model and cores to waste.  We had a discussion
of Disruptor on the mailing list in the past, its quite nice but doesn't
remotely scale up for complicated applications like 0mq can.

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

Financial systems have a huge problem with integration, look at the billion
dollar messaging industry of TIBCO, IBM and Informatica.

> I thought ZeroMQ flagship customers were financial institutions. Then
> maybe I was wrong.
I think its HPC, although I'm certainly using it for financial institutions
for applications when latency and network IO are surprisingly irrelevant
but memory IO, flexibility, simplicity and low learning curve are.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.zeromq.org/pipermail/zeromq-dev/attachments/20120829/78df7bc1/attachment.htm>

More information about the zeromq-dev mailing list