[zeromq-dev] Question about zeromq throughput benchmarks.

Charles Remes lists at chuckremes.com
Thu Mar 27 13:48:09 CET 2014

On Mar 27, 2014, at 4:41 AM, Alexander V Vershilov <alexander.vershilov at gmail.com> wrote:

> Hi,
> I’m trying to write a small benchmark program using zeromq-4.0.4 that will be used as a 
> prototype for higher level library. Test program creates a pair of asynchronous sockets and 
> send a bunch of messages with no acknowledgement and a the end reads a reply.
> Surprisingly, this test program does not compare favourably with an equivalent direct 
> implementation over TCP. I have the following timings for sending 10,000 messages of the 
> given size on the localhost:

This is surprising.

> Is there something I am misunderstanding here? I have gone through several `iterations of 
> my benchmarks, but perhaps you can point out any problem with it?

Have you tried comparing your results to the built-in local_lat/remote_lat and local_thr/remote_thr benchmark programs? You could easily modify the throughput benchmark to use PUSH/PULL sockets and see if the results differ wildly from the pub/sub results.

> At this time I’ve found that PUSH->PULL pattern works well here, however, maybe it’s 
> possible to use some other pattern to reduce cost. Because with  PUSH->PULL pattern on 
> each node I have to create 1 PULL socket, and N PUSH sockets (one per remote host we are 
> connected to).

I don’t fully understand your use-case here. Both a PUSH and PULL sockets may bind or connect multiple times, so you might not need N PUSH sockets. Also, PUSH/PULL are generally used for uni-directional communication where all data flows from a producer (PUSH) to a sink (PULL). If you need responses to flow back, you may want to consider DEALER/ROUTER which are utilized for bi-directional protocols.

Take a look at the majordomo example in the zguide. It’s the most useful general purpose “pattern” for bi-directional communications and may fit your use-case.


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

More information about the zeromq-dev mailing list