zeromq- pub/sub模式 测试
来源:互联网 发布:院长入额首选知产团队 编辑:程序博客网 时间:2024/05/17 08:21
相关术语:
- 吞吐量(throughput):messages per second(msg/s)
- On :第n个消息被发送时的时间
- In :第n个消息被接收时的时间
- SOn :第n个消息的发送开销(s)
- ROn :第n个消息的接收开销(s)
- STn :当第n个消息正在被发送时的吞吐量(msg/s)
- RTn :当第n个消息正在被接收时的吞吐量(msg/s)
涉及的变量:
- message_size :每个消息的大小(B)
- message_count : 消息的个数
吞吐量计算公式:
- 发送端:STn = M / ( On - On-M )
- 接收端:RTn = M / ( In - In-M )
【Measuring messaging performance - zeromq 】给出了 M 的经验取值, M = 100 时比较好.
实验设计:
- 1个publisher,1个subscriber,固定message_size, 衡量message_count的变化对throughput的影响
message_size = 2000 B
发送者发送10000个message,接收者接收10000个message,记录On、In,计算STn 、RTn
- 1个publisher,1个subscriber, 固定message_count, 衡量message_size的变化对throughput的影响
吞吐量的表示:messages/second 、megabits/second;
吞吐量取值: 取中间值(median:n个元素按照升序排序,第N/2个数,如果有两个,取前一个较小的数);
message_size的取值:1000B、2000B、3000 B、4000 B、5000 B 、6000 B、7000 B、8000 B、9000 B、10000 B;
每个message_size取值情况下: 发送者发送100000个message,接收者接收100000个message,记录On、In,计算STn 、RTn 。
- 1个publisher,10个subscriber,固定message_size,衡量message_count对throughput的影响
message_size = 2000 B
- 1个publisher,1个subscriber,1个proxy,固定message_size,衡量message_count对throughput的影响
message_size = 2000 B
- 1个publisher,5个subscriber,1个proxy,固定message_size,衡量message_count对throughput的影响
message_size = 2000 B
在进行实验之前,需要弄清楚:
- zmq_send( )的发送是往队列中发,是异步的还是同步的?
- zmq_send( )是如何保证消息能够从队列中发送到网络里(0MQ has assumed responsibility for the message)?
- pub-sub模式中,1个pub,10个sub的情况,是如何发的?
- 当前的网络环境如何?监控下带宽。
当前的环境(虚拟机):
- zeromq 3.2.2
- CentOS 6.3 (32bit)
- 1Gb Network
- 4G Memory
- Intel(R) Core(TM)2 Duo CPU T7700 @ 2.40GHz
带宽瓶颈: 35 MB/s 左右
- 1 个 publisher,1 个 subscriber:send peak 和 recv peak 相当,达到带宽瓶颈
- 1 个 publisher,5 个 subscriber:send peak ≈ ∑ recv peaks ,可以考虑使用多播,epgm/pgm
- 1 个 publisher,2 个 subscriber :发 400 MB,每一个subscriber 接收 400 MB,但publisher的网络端口检测到流出800 MB数据,每个subscriber端口检测到流入400 MB数据。
- 带proxy的模式下,pub-proxy-sub( N 个)的流量比例是 1:N:1(N个sub,每个1份)
hwm设置问题
遇
http://stackoverflow.com/questions/13867942/what-are-appropriate-settings-for-zmq-when-sending-500k-64-byte-messageshttp://stackoverflow.com/questions/10183539/pub-sub-implementation-zero-mq-3-xxhttp://stackoverflow.com/questions/16228484/zeromq-c-is-it-necessary-to-set-a-high-water-mark-for-subscribers/16432160#16432160http://stackoverflow.com/questions/11119550/how-to-receive-missed-messages-for-1-of-n-subscribers-in-zeromq/11125230#11125230实验:实验设计 1:
1个publisher,1个subscriber,固定message_size, 衡量message_count的变化对throughput的影响
发送者发送 ≥ 10000个message,接收者接收10000个message,记录 In,计算 RTn = M / ( In - In-M ) , M = 100message_size = 2000 B
M 为 100,需做到:接收的message总个数 N >> M
根据实验和计算结果,绘图如下:
在message size为恒定的常量时,messages/second 和 megabits/second 是同构的,是用来度量吞吐量的两种表示方式。在这里使用messages/second来表示, message_size = 2000 B 。在 publisher:subscriber = 1 : 1 的情况下,接收随着message数量的变化,吞吐量的范围在5000 ~ 220000 messages/second ,即 10 MB ~ 44MB/second,吞吐量偶然的峰值达到44 MB/s,而由之前对网络环境的测试中,带宽瓶颈约等于 35 MB/s。说明,接收速率已达到带宽上限,网络带宽是瓶颈问题,增加网络带宽,可能会提高接收速率。实验设计2:1个publisher,1个subscriber, 固定message_count, 衡量message_size的变化对throughput的影响传输不同大小的message,对吞吐量的影响。在message size为变量的情况下,messages/second 和 megabits/second 是异构的,吞吐量的表示有不同,在某些情况下甚至互为倒数。随着message_size的增大,每秒钟接收的message总数减少,每秒钟接收的字节数增加,直到接近网络带宽瓶颈。由前面的对网络环境的测试中,了解到,当前千兆网卡,带宽瓶颈 ≈ 35 MB/s = 272 Mb/s实验设计3:1个publisher,10个subscriber,固定message_size,衡量message_count对throughput的影响,message_size = 2000 B在 publisher:subscriber = 1 : 10 的情况下,接收随着message数量的变化,每一个subscriber的吞吐量的范围在500 ~ 3000 messages/second , 即 1 MB ~ 6 MB/second,吞吐量偶然的峰值达到6 MB/s,10个subscriber的吞吐量总和在5000 ~ 23000 MB/second, 即 10 MB ~ 46 MB/second,而由之前对网络环境的测试中,带宽瓶颈约等于 35 MB/s,说明,接收速率已达到带宽上限,网络带宽是瓶颈问题,继续增加subscriber的个数,吞吐量总和不会再有所增加。实验设计4:1个publisher,1个subscriber,1个proxy,固定message_size,衡量message_count对throughput的影响。message_size = 2000 B在 publisher:proxy : subscriber = 1 : 1 : 1 的情况下,接收随着message数量的变化,吞吐量的范围在2700 ~ 6000 messages/second ,即 5.4 MB ~ 12MB/second,吞吐量偶然的峰值达到 12 MB/s,而由之前对网络环境的测试中,带宽瓶颈约等于 35 MB/s。说明,接收速率还未达到带宽上限。导致吞吐量下降的原因,可能是由于增加了proxy,proxy拖慢了发送给subscriber的速度,网络带宽是不是当前吞吐量的瓶颈问题。实验设计5:1个publisher,N个subscriber,1个proxy,固定message_size,衡量message_count对throughput的影响。 message_size = 2000 Bpublisher : proxy : subscriber = 1 : 1 : 5的情况下,每个subscriber的接受速率在500 ~ 2500 messages/second , 即 1 ~ 5 MB/second,吞吐量偶然的峰值达到5 MB/s,5个subscriber的吞吐量总和在3000 ~ 11000 MB/second, 即 6 MB ~22 MB/second,而由之前对网络环境的测试中,带宽瓶颈约等于 35 MB/s,说明,接收速率仍未达到带宽上限,网络带宽是不是吞吐量的瓶颈问题,继续增加subscriber的个数,吞吐量可能会有所增加。publisher : proxy : subscriber = 1 : 1 : 7的情况下,每个subscriber的接受速率在300 ~ 2500 messages/second , 即 0.6 ~ 5 MB/second,吞吐量偶然的峰值达到5 MB/s,7个subscriber的吞吐量总和在3000 ~ 14000 MB/second, 即 6 MB ~28 MB/second,而由之前对网络环境的测试中,带宽瓶颈约等于 35 MB/s,说明,接收速率仍未达到带宽上限,网络带宽是不是吞吐量的瓶颈问题,继续增加subscriber的个数,吞吐量可能会有所增加。publisher : proxy : subscriber = 1 : 1 : 10的情况下,每个subscriber的接受速率在200 ~ 2000 messages/second , 即 0.4 ~ 4 MB/second,吞吐量偶然的峰值达到4 MB/s,10个subscriber的吞吐量总和在3000 ~ 16000 MB/second, 即 6 MB ~32 MB/second,而由之前对网络环境的测试中,带宽瓶颈约等于 35 MB/s,说明,接收速率仍未达到带宽上限,网络带宽是不是吞吐量的瓶颈问题,继续增加subscriber的个数,吞吐量可能会有所增加。
- zeromq- pub/sub模式 测试
- ZeroMQ之PUB/SUB模式
- 004 ZeroMQ <PUB XSUB-XPUB SUB>模式
- zeroMQ初体验-2.发布订阅模式(pub/sub)
- 002 ZeroMQ PUB and SUB
- zeroMQ 简单的PUB-SUB 高性能模式,java 语言版本
- Redis的Pub/Sub模式
- zeromq/jzmq pub/sub发布订阅java代码
- redis的pub/sub性能测试
- pub/sub模式的jquery插件
- Apache Stratos探究:Pub-Sub 通信模式
- nanomsg的pub/sub模式用法
- zeromq/jzmq 基于信封-内容的pub/sub发布订阅java代码
- MQTT服务器的搭建与测试pub/sub通信过程
- JMS的两种模式 P2P,PUB/SUB
- 【Redis】redis介绍-订阅推送(pub/sub)模式
- pyzmq的4种模式(PUB/SUB)笔记
- ActiveMQ两种模式PTP和PUB/SUB
- [Unity3D]在Unity3D中Javascript的基本使用与介绍
- PHP_保留两位小数并且四舍五入_保留两位小数并且不四舍五入
- IT同行请教我如何培养读书习惯,结果就是“读了1本书,并写下'读《成交》有感'一文”
- C++中构造函数默认参数学习笔记
- 管理位图内存
- zeromq- pub/sub模式 测试
- 查杀占用网络资源的升级版ipz.exe与ipz2.exe病毒
- 用内存映射实现posix消息队列
- c++模板函数声明定义分离编译错误详解
- 顾大局 识大体
- SpringMVC redirect 重定向 中文乱码
- 6133 Cellphone Typing (trie)
- VM下搭建hadoop集群
- C++和Java创建对象的不同