zmq是基于tcp实现的吗_zmq的pub/sub模式下inproc,ipc,tcp,epgm的通信性能测试结果以及分析(二)...

将结果整理如图:

[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端收到的包顺序混乱的情况。

  • 0
    点赞
  • 1
    收藏
    觉得还不错? 一键收藏
  • 0
    评论

“相关推荐”对你有帮助么?

  • 非常没帮助
  • 没帮助
  • 一般
  • 有帮助
  • 非常有帮助
提交
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值