测试环境及工具

  • EMQ X 版本:4.0.5
  • 测试工具:XMeter 企业版私有部署、mqtt-xmeter 插件 1.14
  • 测试环境:青云,上海 1 区内网
  • EMQ X 服务器配置:1 台,centos 7.5,16 核 32G, 内网 ip: 192.168.0.5
  • XMeter 服务器配置:2 台,centos 7.3,4 核 8G,内网 ip: 192.168.0.8, 192.168.0.10
  • 压力机配置:10 台,centos 7.3,8 核 8G

发布、订阅场景 N Pub+N Sub

模拟发布订阅场景,该场景下发布客户端个数和订阅客户端个数相同都为 N,主题数也是 N 个,每个发布客户端每秒发送 1 个报文,因此总的吞吐为 2N。测试中从 N=2 万开始,并通过增加客 户端个数 N 来逐步增加负载,分别找出在 QoS 为 0、1、2,payload 长度为 16、2000 字节组合下的 极限和性能拐点。

注:由于 QoS 为 0 时发布报文没有应答报文无法计算响应时间,因此在测试中通过设计脚本确 保某台测试机上发布的报文由该台机器上的客户端订阅、消费,通过计算发送报文所带时间戳和接 收报文所带时间戳的差来得到 QoS 为 0 时 sub 的响应时间。

测试小结

  1. 测试了几个用例,订阅主题层级分别设为 3 层和 6 层,测试结果(包括响应时间、资源消耗等)差异不明 显;因此在用例设计上没有区分主题层级,均按照 3 层来测试。

  2. 当其他条件一样,仅改变 payload 长度。测试发现如果 payload 长度在 1k 以内,除了网络,其他指标包括 响应时间、cpu/memory 消耗都相差无几,因此测试场景中 payload 长度设为 16 和 2000 字节进行比较

  3. 为了比较订阅主题是否包含通配符时响应时间和系统资源使用情况的不同,增加了一组订阅主题带有#的 测试

  4. QoS 为 0,当 N=8 万,即设置的总吞吐量为 16 万,payload 长度为 2000 字节时,测试结果表明此场景压 力已超过该配置下的 EMQ X 能力,测试中出现错误,实际总吞吐为 13 万左右

  5. QoS 为 1,当 N=6 万,即设置的总吞吐量为 12 万,payload 长度为 2000 字节时,测试中虽然没有出现错 误,但实际总吞吐只有 8 万 4 左右

  6. QoS 为 2,当 N=6 万,即设置的总吞吐量为 12 万,payload 长度为 2000 字节时,测试结果表明此场景压 力已超过该配置下的 EMQ X 能力,测试中出现错误,实际总吞吐仅为 6 万不到

  7. 测试结果曲线图 image.png

image.png

image.png

image.png

想要获取完整版?

下载地址将会发送至您填写的邮箱