zeromq 性能测试.准确的延迟是多少? [英] zeromq performance test. What's the accurate latency?

问题描述

我正在使用 zmq 跨进程传输消息，我想做一些性能测试以获取延迟和吞吐量.

I'm using zmq to carry message across process, and I want to do some performance test to get the latency and throughout.

官网给出指南告诉如何运行性能测试

例如，我试过:

local_lat tcp://*:15213 200 100000
remote_lat tcp://127.0.0.1:15213 200 100000

并得到结果:

message size: 200 [B]
roundtrip count: 100000
average latency: 13.845 [us]

但是在尝试 pub-sub 示例时C++，我发现发送和接收之间的时间间隔大约是150us.(我通过带时间戳的打印日志得到结果)

But when trying the pub-sub example in C++, I found the time interval between sending and receiving is about 150us. (I get the result by print log with timestamp)

谁能解释一下这两者之间的区别?

Could anybody explain the difference between these two?

我发现了一个问题 0mq:pubsub 延迟随着消息不断增长?结果给出了几乎恒定的 0.00015s 延迟，即 150us，与我的测试相同，是官方性能测试的 10 倍.为什么有区别?

I found the question 0mq: pubsub latency continually growing with messages? The result give a nearly constant delay of 0.00015s, which is 150us, same as my test, 10x than the official performance test. Why is the difference?

推荐答案

我遇到了同样的问题:ZeroMQ - 发布/订阅延迟

我在我的示例代码上运行了wireshark，它每秒发布一条 zeromq 消息.这是wireshark的输出:

I ran wireshark on my example code which publishes a zeromq message every second. Here is the output of wireshark:

145  10.900249     10.0.1.6 -> 10.0.1.6     TCP 89 5557→51723 [PSH, ACK] Seq=158 Ack=95 Win=408192 Len=33 TSval=502262367 TSecr=502261368
146  10.900294     10.0.1.6 -> 10.0.1.6     TCP 56 51723→5557 [ACK] Seq=95 Ack=191 Win=408096 Len=0 TSval=502262367 TSecr=502262367
147  11.901993     10.0.1.6 -> 10.0.1.6     TCP 89 5557→51723 [PSH, ACK] Seq=191 Ack=95 Win=408192 Len=33 TSval=502263367 TSecr=502262367
148  11.902041     10.0.1.6 -> 10.0.1.6     TCP 56 51723→5557 [ACK] Seq=95 Ack=224 Win=408064 Len=0 TSval=502263367 TSecr=502263367

如您所见，发送和确认每条消息大约需要 45 微秒.起初我以为每条消息都会重新建立连接，但事实并非如此.所以我把注意力转向了接收器......

As you can see it's taking about 45 microseconds to send and acknowledge each message. At first I thought that the connection was getting re-established on each message but that's not it. So I turned my attention to the receiver...

while(true)
    if(subscriver.recv(&message, ZMQ_NOBLOCK)) {
        // print time
    }
}

通过添加 ZMQ_NOBLOCK 并在硬循环中进行轮询，我将时间缩短到 100 微秒.这看起来仍然很大，而且是以增加一个核心为代价的.但我确实觉得我对这个问题的理解稍微好一点.任何见解将不胜感激.

By adding the ZMQ_NOBLOCK and polling in a hard while loop I got the time down to 100us. That still seems large and it comes at the price of spiking one core. But I do feel like I understand the problem slightly better. Any insight would be appreciated.

这篇关于zeromq 性能测试.准确的延迟是多少?的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！