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

Chuck Remes lists at chuckremes.com
Thu Aug 30 00:28:56 CEST 2012


On Aug 29, 2012, at 4:46 PM, Julie Anderson wrote:

> See my comments below:

And mine too.

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

What numbers? Only you have produced them so far. 

We have been quite patient with you. It appears you have some experience, so I'm confused as to why you refuse to provide any code for the rest of us to run to duplicate your results. If the roles were reversed I am certain you would want to run it yourself.

If you want our help, don't tell us to "google" some code to run. If it's really that easy then provide a link and make sure that your numbers are coming from the exact same code. Until someone else can independently verify your numbers then everything you have written is just smoke.


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

I would be surprised too. Zeromq doesn't solve the same problem as Disruptor.

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

Don't be insulting. It doesn't help you or inspire anyone here to look into your claims.

cr

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


More information about the zeromq-dev mailing list