白皮书
车云灵活数采方案：释放数据价值，加速智能创新 →

测试目的

在 EMQX 3.0 版本时我们已做过千万连接和百万消息吞吐的基准测试，那次测试使用了 20 个 EMQX 节点的集群，每个节点所在机器为 16 核 32G。

在 4.0 和后续的 4.2，4.3 版本中，我们在架构、内部模块上重新设计和不断优化，大幅提升了 EMQX 的性能。本次测试将展现 EMQX 4.3 在大规模 MQTT 并发连接、主题订阅以及高消息吞吐上的能力，被测集群只有 5 个节点，每个节点所在机器资源为 32 核 64G。

测试场景

本次测试使用华为云主机，5 个 EMQX 节点和测试机在同一个 vpc 中，主要进行了 1 千万的 MQTT 连接、1 千万的主题订阅加上 QoS0 百万消息吞吐，和 QoS1 50 万消息吞吐场景，具体如下所示。

注：如果不做特别说明，所有的连接默认都设置了 300 秒的心跳时间，所有的消息 payload 均为 50 字节。

场景一：1000 万 MQTT 连接、订阅 + QoS0 广播场景百万消息吞吐

1000 万 MQTT 客户端以每秒 2 万的新增连接速率接入EMQX 集群，每个客户端连接成功后均订阅一个主题，每 10 个连接订阅一个相同的主题，因此测试达到 100 万主题、1000 万订阅。1000 万连接和订阅完成后开始进行消息广播场景（接收端数量远大于发送端），50 个 MQTT 连接作为 pub 客户端发送消息，每 10 个为一组向主题testn/${machineName()}/${threadNum}（n为1～5）发送消息，每个pub客户端每秒发送 100 条 QoS0 消息，1000 个 sub 客户端也分成 5 组每组 200 个订阅主题 testn/#（n为1～5）。

因此，总的消息发布吞吐率为每秒 5000 条，总的消息接收吞吐率达到每秒 100 万。

场景二：1000 万 MQTT 连接、订阅 + QoS0 1 对 1 百万消息吞吐

MQTT 1000 万连接、订阅和上面的场景一相同。1000 万连接和订阅完成后开始进行 1 对 1 消息收发（接收端数量等于发送端，每个接收端订阅一个对应的发送端 pub 主题），pub 客户端和 sub 客户端都是 25000 个，每个pub客户端每秒发送 20 条 QoS 0 消息，相应的每个 sub 客户端消费 20 条 QoS 0 消息，因此消息发送和接收均为每秒 50 万条，总的消息吞吐达到 100 万。

场景三：1000 万 MQTT 连接、订阅 + QoS1 广播场景 50 万消息吞吐

MQTT 1000 万连接、订阅和上面的场景 1 相同。1000 万连接和订阅完成后开始进行 QoS 为 1 的消息广播场景（接收端数量远大于发送端），50 个 MQTT 连接作为 pub 客户端发送消息，每 10 个为一组向主题testn/${machineName()}/${threadNum}（n为1～5）发送消息，每个 pub 客户端每秒发送 50 条 QoS 1 消息，1000 个 sub 客户端也分成 5 组每组 200 个订阅主题 testn/#（n为1～5）。

因此，总的消息发布吞吐率为每秒 2500 条，总的消息接收吞吐率达到每秒 50 万。

场景四：1000 万 MQTT 连接、订阅 + QoS1 50 万 1 对 1 消息吞吐

MQTT 1000 万连接、订阅和上面的场景 1 相同。100 万连接和订阅完成后开始进行 QoS 为 1 的 1 对 1 消息收发（接收端数量等于发送端，每个接收端订阅一个对应的发送端 pub 主题），pub 客户端和 sub 客户端都是 25000 个，每个 pub 客户端每秒发送 10 条 QoS 1 消息，相应的每个 sub 客户端消费 10 条 QoS 0 消息，因此消息发送和接收均为每秒 25 万条，总的 QoS 1 消息吞吐达到 50 万。

测试结果概述

场景一：1000 万 MQTT 连接、订阅 + QoS0 广播场景百万消息吞吐

  • 平均连接速率达到 2 万/秒，连接 + 订阅平均响应时间 4.2ms
  • Sub 平均响应时间 0.33ms
  • 每个节点 EMQX CPU 平均使用 34%，1千万客户端全部连接后消息收发期间每节点 EMQX CPU使用范围为 32%～60%
  • 每个节点 EMQX 内存平均使用 28.4GB，1千万客户端全部连接后消息收发期间每节点 EMQX 内存使用范围为 29GB～35.4 GB
最小响应时间 (s) 最大响应时间(s) 平均响应时间(s) 平均吞吐量 EMQX CPU 使用 EMQX 内存使用(G)
MQTT 连接 0.002 0.03 0.0042 19978 32%～60% 29～35.4
MQTT Pub / / / 5002.462
MQTT Sub 0 0.178 0.0003 1000490

场景二：1000 万 MQTT 连接、订阅 + QoS0 1 对 1 百万消息吞吐

  • 平均连接速率达到 2 万/秒，连接 + 订阅平均响应时间 5ms
  • sub 平均响应时间 0.3ms
  • 每个节点 EMQX CPU 平均使用 51%，1 千万客户端全部连接后消息收发期间每节点 EMQX CPU 使用范围为 56%～68%
  • 每个节点 EMQX 内存平均使用 28.7GB，1 千万客户端全部连接后消息收发期间每节点 EMQX 内存使用范围为 28.6GB～35.2 GB
最小响应时间(s) 最大响应时间(s) 平均响应时间(s) 平均吞吐量 EMQX CPU 使用 EMQX 内存使用(G)
MQTT 连接 0.002 3.076 0.005 19923 56%～68% 28.6～35.2
MQTT Pub / / / 505045
MQTT Sub 0 0.04 0.0003 502322

场景三：1000 万 MQTT 连接、订阅 + QoS1 广播场景 50 万消息吞吐

  • 平均连接速率达到 2 万/秒，连接+订阅平均响应时间 4.6ms
  • pub 平均响应时间 1ms，sub 平均响应时间 0.3ms
  • 每个节点 EMQX CPU 平均使用 38%，1 千万客户端全部连接后消息收发期间每节点 EMQX CPU 使用范围为 35%～57%
  • 每个节点 EMQX 内存平均使用 28.5GB，1 千万客户端全部连接后消息收发期间每节点 EMQX 内存使用范围为 29.6GB～33.8GB
最小响应时间(s) 最大响应时间(s) 平均响应时间(s) 平均吞吐量 EMQX CPU 使用 EMQX 内存使用(G)
MQTT 连接 0.002 0.37 0.0046 19998 35%～57% 29.6～33.8
MQTT Pub 0 0.123 0.001 2607
MQTT Sub 0 0.116 0.0003 521555

场景四：1000 万 MQTT 连接、订阅 + QoS1 50 万 1 对 1 消息吞吐

  • 平均连接速率达到 2 万/秒，连接 + 订阅平均响应时间 4.5ms
  • pub 平均响应时间 1.1ms，sub 平均响应时间 0.6ms
  • 每个节点 EMQX CPU 平均使用 48%，1 千万客户端全部连接后消息收发期间每节点 EMQX CPU 使用范围为 50%～65%
  • 每个节点 EMQX 内存平均使用 28.8GB，1 千万客户端全部连接后消息收发期间每节点 EMQX 内存使用范围为 GB～GB
最小响应时间(s) 最大响应时间(s) 平均响应时间(s) 平均吞吐量 EMQX CPU使用 EMQX 内存使用(G)
MQTT 连接 0.002 3.022 0.0045 19803 50%～65% 30.9～36.4
MQTT Pub 0 0.283 0.0011 249192
MQTT Sub 0 0.03 0.0006 521555

测试环境及部署

华为云中的测试部署如下所示，本次测试共使用 40 台测试机，其中 20 台每台模拟 50 万 MQTT 连接，20 台模拟百万 QoS 0 消息吞吐 / 50 万 QoS 1 消息吞吐。XMeter 提供的基于 JMeter MQTT 插件的测试工具来模拟业务测试场景；XMeter 内置支持的监控工具用于监控 3 台被测 EMQX 集群的资源使用情况。

测试环境结构图

EMQX / XMeter配置：

节点 数量 版本 操作系统 CPU 内存 硬盘
EMQX 5 企业版v4.3.0 Centos 7 32核 64G 40G
XMeter管理机 2 企业版v3.0 Centos 7 16核 32G 40G
XMeter压力机 40 企业版v3.0 Centos 7 16核 32G 40G

EMQX 集群安装

EMQX 安装成功并加入集群后，使用命令行显示总共安装了 5 个 EMQX 的节点。

Cluster status: #{running_nodes =>               

​           ['emqx@192.168.0.30','emqx@192.168.0.31',

​            'emqx@192.168.0.33','emqx@192.168.0.36',

​            'emqx@192.168.0.8'],           

​         stopped_nodes => []}

详细测试结果

详细测试结果请填写右侧表单获取完整版 PDF 文件。

联系我们