[zeromq-dev] inproc message delivery

Marlborough, Rick RMarlborough at aaccorp.com
Thu Apr 6 14:49:01 CEST 2017

Designation: Non-Export Controlled Content
  Thanx for your response. We have done most of our testing with 1000 byte messages. The 2 endpoint types are ZMQ_REQ and ZMQ_REP. Our loop is a simple tight loop,  no sleeps. And yes you are correct, I meant to say "inproc should be blazing fast compared to ipc".


From: zeromq-dev [mailto:zeromq-dev-bounces at lists.zeromq.org] On Behalf Of Thomas Rodgers
Sent: Wednesday, April 05, 2017 5:44 PM
To: ZeroMQ development list
Subject: Re: [zeromq-dev] inproc message delivery

I assume you meant to say 'inproc' would be blazing fast compared to 'ipc'?

What message size(s) have you tried?

I'm not convinced this is a reasonable expectation, particularly with smallish messages. IPC transport is going to involve a few more kernel calls but at the end of the day, it's still memory -> memory, and the improc socket type still has most of the zmq socket machinery to traverse.


On Wed, Apr 5, 2017 at 4:34 PM Marlborough, Rick <RMarlborough at aaccorp.com<mailto:RMarlborough at aaccorp.com>> wrote:

Designation: Non-Export Controlled Content
    We are testing message delivery between 2 zmq sockets. We have done testing over the network between 2 nodes, on a single node and within a single process. For the single process case we use inproc transport. When we examine the delivery times we find that single node ipc transport is better than network. Surprisingly, inproc transport performance is virtually indistinguishable from ipc transport. I would expect ipc to be blazing fast in comparison. For the record we are using ZeroMQ 4.2.2 on red hat 7 64 bit. What should I expect using ipc transport?


zeromq-dev mailing list
zeromq-dev at lists.zeromq.org<mailto:zeromq-dev at lists.zeromq.org>

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

More information about the zeromq-dev mailing list