lantency.rst

往返时延测试

2万QoS1消息分发时延

时延测试需要PUB端和SUB端一起配合才能得到指标，测试场景设计如下：

1. PUB端发出的消息Payload中包括了：
   1. 标识该条消息的唯一id：机器名 + 线程号 + 消息ID
   2. 发出该消息的时间戳
   3. 实际数据，大小视测试场景而定
2. EMQ消息服务器进行转发。
3. SUB端收到消息时，解开消息Payload，收到消息时候的时间戳与PUB端发出的时间戳进行相减得到该消息的时延，并将消息ID和时延存入文件${hostname}_ data_entries.log。
4. 分析${hostname}_ data_entries.log的结果，得到平均时延和丢包率。

Note

由于EMQ的消息时延比较低，如果PUB和SUB不在同一台机器上的话，由于机器之间的时间不能完全同步，会导致上述第三步得到时延值不准确，因此该场景需要保证PUB和SUB运行在同一台机器上。

总体结果：在工作负载比较正常的情况下，2万QoS1消息时延大约为60ms(测试机和压力机都处于青云内部网络，网络延迟比较小)，消息无丢失。在工作负载比较大的情况下，消息时延大幅增加，在下表场景2的结果中，消息时延增加到77秒，但是消息无丢失，消息发送的时间段大幅拉长。

组合场景ID	Payload	Qos	PUB	SUB	消息速率	背景连接	平均吞吐量
1	1k	1	20 x 1	1000	20k	20k	19.35k

CPU	Mem	消息转发情况
CPU利用率最高不超过86%， shortterm load不超过7	Memory占用低于1G	实际每秒fanout的消息数量跟期望比较一致， 息时延约为61ms，消息无丢失

Note

注1：测试机配置：1台虚拟机支持20000 VU(2个docker*10000 VU)

Note

注2：PUB列(m*n)，其中m表示PUB端的连接个数，n表示每秒发出消息的频率。那么10*1表示10个PUB端每秒发出1条消息。

Note

注3：绿色背景的测试是合法测试，红色背景的是有问题的测试，点击测试ID可以查看详细测试报告。