zeromq- pub/sub模式 测试

相关术语：

• 吞吐量（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-messages

http://stackoverflow.com/questions/10183539/pub-sub-implementation-zero-mq-3-xx

http://stackoverflow.com/questions/16228484/zeromq-c-is-it-necessary-to-set-a-high-water-mark-for-subscribers/16432160#16432160

http://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的影响

   message_size = 2000 B

             发送者发送 ≥ 10000个message，接收者接收10000个message，记录  In，计算  RTn = M / ( In - In-M ) ，  M = 100

            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 B

publisher : 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的个数，吞吐量可能会有所增加。

•