zmq的pub/sub模式下inproc,ipc,tcp,epgm的通信性能测试结果以及分析(二)

Posted 2023-04-12

参考技术A 将结果整理如图：

[if !vml]

[endif]

            （epgm后面四个时间因为过大，没有放进图中）

       通过对比，我们可以看出：

[if !supportLists]1.    [endif]四种方式的传输时间都随pub端发送消息的空间大小的增加而增加，在消息超过512kb之后，传输时间的增加速度变大，且tcp和ipc这两种方式最为明显。

[if !supportLists]2.    [endif]三种通信方式中，inproc 的速度远小于其他两种，特别是随着消息字节数增加，其性能优势愈发明显。

[if !supportLists]3.    [endif]比较tcp ，ipc和epgm ，可以看出在字节数小于65536的大多数情况下，三者差距不大。

[if !supportLists]4.    [endif]综合来看，inproc 的通信性能在当前情景下最有优势。

结果分析

对于以上的测试结果中inproc通信性能优势，通过参考 http://api.zeromq.org/4-2:zmq-inprocd 说明，可知zmq inproc是在单个进程中的不同线程之间传输。也就是说，不同的线程之间共享使用同一个ZMQ 环境上下文，如下，将新创建的上下文传递给子线程。

 

[if !vml]

[endif]

   已知zmq 通信用于node 和node之间，可以是主机或者是进程。结合以上inproc的特点，可以表明，对于一个采用inproc 的sub端来说，它会与同一进程中不同线程中的节点通信。而对于采用ipc 的传输来说，它会与同一主机不同进程上的节点通信，对于tcp 的sub端来说会与其他远程主机（本次测试都在本机）上的节点通信。

因此，使用inproc或ipc这样的传输，在正确的上下文中使用它们时，这两者比tcp传输速度更快，更高效。

Epgm采用的是udp协议对数据进行传输，而udp的设计传输极限不超过65535个字节，因此会在传输层进行数据分包，间隔一段时间再发送, 所以再字节数超过65535的测试中，时间都远超其他几种。

一些想法

基于zmq的特点，实际上在大多数情况下的远程服务器之间的传输，都只需要使用TCP传输，可以使用多对套接字。因为这样的应用场景，相对与socket的1对1 的关系，ZMQ 可以用N：M 的关系，在开发上zmq省略的细节，降低了开发难度。因此，如果要通过网络与其他计算机通信，请使用TCP。 

而在上文的测试中表明了inproc使用在同一个进程的线程之间，ipc表示本地进程之间，tcp表示远程进程之间。 因此，如果我们的场景是在多个不同的进程之间切换，但都在同一个逻辑服务器实例上，那么IPC传输可能是最佳选择。如果是在同一个进程之间，那么inproc 更为适合。Zmq的sub/pub可以在同一进程中，也可以在多个进程中（在远程和同一服务器实例中都可以）。我们可以根据应用场景的不同进行选择。

参考官方文档，可以知道epgm常用在mutilecasts的模式下。测试中也提示了我们使用过程中的注意事项，例如一次性传输数据超出限制，如果存在有多个发送端，某pub端发送的一次数据量过大，则可能出现sub端收到的包顺序混乱的情况。

zmq ipc方式进程间通信ipc文件被占用问题

测试步骤

1.启动pub.py  ->  启动sub.py  ->  sub.py可以收到数据，注意这个时候由于pub.py,sub.py是ipc

通讯，会产生ipc通信文件。假如ipc文件为 file.ipc

2.分别ctrl + z 退出pub.py sub.py, 注意这个时候提示的stoped已经停止。

3.启动sub.py  -> 启动pub.py  -> sub.py收不到数据。

 

暂时结论

由于2步骤中的操作是ctrl+z，这个时候ps -axu, 发现1步骤中的pub.py sub.py进程其实还在，也

就是说pub.py sub.py都还占用这file.ipc文件。这个时候在按3步骤sub.py, pub.py去操作，1步骤

中的pub.py sub.py进程已经被占用file.ipc。这个时候3步骤中的sub.py是收不到数据的。