[zeromq-dev] Measuring Performance Publish & Subscribe

sta318 at web.de sta318 at web.de
Sun Jul 17 10:10:17 CEST 2016


Hi Team,

 

i am measuring the latency of the publish & suscribe pattern using protobuf.
I am using zeromq 4.1.3 on an windows 7 embedded. The publisher & subscriber
are written in C++.

 

The publisher and the subscriber are on the same system. I wrote two protos
which both use. For measuring the latency i am using the Windows High
Precision Event Timer.

In one protobuf object the data is stored. In the other protobuf object the
systemclocks from the publisher are stored in. On the publisher site the
system cycles after the start are wrote in the protobuf object. The objects
are sent in a multipart message. When the subscriber gets the messages, he
calculates the difference and gets the latency in microseconds.

 

When the payload is maller than 300.12 kB i get logic results. But when the
payload is 300.12 kB or bigger i get this huge results. 

 


Payload (kB)  AverageLatency (us)


300.12            7.8928e+06


600.12           5.6801e+06


1200.1           5.3435e+06


3000.1           5.2595e+06

 

When i look directly into the logs i see this behaviour:

For a payload of 300.12:

MessageNo. Payload (kB)   Latency (us) 

233                         300.125            3961

234                         300.125   11131668

 

The same for a Payload of 600.12

MessageNo. Payload (kB)   Latency (us) 

489                       0.600125          8799

490                       0.600125 11083799

 

The same for a Payload of 1200.13

MessageNo. Payload (kB)   Latency (us) 

548                         1.20013        17555

549                         1.20013 11082562

 

The same for a Payload of 1200.13

MessageNo. Payload (kB)   Latency (us) 

55                           3.00012       45364

56                           3.00012 11164985

 

I don't understand the explosion of the latency. Is there a timeout or what
happened?

What makes ZeroMQ in the background?

 

Regards

Sebastian

 

 

 

 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.zeromq.org/pipermail/zeromq-dev/attachments/20160717/0b7c680d/attachment.html>


More information about the zeromq-dev mailing list