[zeromq-dev] What is the expected performance on IPC sockets?

[Chinmay Nerurkar]

As per the conclusion to http://permalink.gmane.org/gmane.network.zeromq.devel/19334 I am testing the performance of  IPC PUB-SUB on a linux machine (2x Intel(R) Xeon(R) CPU E5-2690 0 @ 2.90GHz, 64 GB RAM) using JZMQ 2.1.0 based on ZeroMQ 3.2.3.

I have two processes here.
- The subscribing process creates a ZMQ context with one thread, ZMQ Sub socket (HWM = 100000), connects to "ipc://outbound" and subscribes to "TEST" topic. This process is started first.
- The publishing process creates a ZMQ context with one thread, ZMQ PUB socket (HWM = 100000) and binds to "ipc://outbound". Then it waits a second before it starts publishing 100 million messages of 96 bytes each (including header) in a while(1) loop. Before starting to publish messages I sleep for 1 second after 'socket bind' to let the connection complete with the subscriber. I make the process sleep for 1 millisecond every 1000 messages sent to slow it down to around 300K messages per second (I know this is kind of hacky. Is there a better way?)

Here is what I see.
- If the data rate is around 300k messages I get all the messages on the subscriber.  If I go any faster messages are dropped. I would have expected it to go much faster since it is no longer relying on network stack and is on the same host using unix domain sockets. If I understand this, the unix socket should not drop data unless it is out of memory. Is there some mechanism in ZMQ that makes it drop messages based on some constraint? What is the performance I should expect over IPC for ~100 byte messages on the setup I have described above?
- If I gave the Publisher 2 ZMQ context threads and the subscriber 4 context threads just to check, the publisher's send rate slowed down to around 180K messages a second. Shouldn't the performance have gone up?
- Is there a better design to use IPC PUB-SUB between processes that I am clearly missing here?


Thanks.

Chinmay
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.zeromq.org/pipermail/zeromq-dev/attachments/20130613/4df82053/attachment.htm>