一、关于杭州映云科技和EMQX
杭州映云科技有限公司是一家物联网基础设施软件供应商，服务新产业周期的 IoT&5G、边缘计算与云计算市场，交付全球领先的开源物联网消息服务器和流 处理数据库，提供实时物联网数据移动、分发、流处理与分析一站式解决方 案。 公司成立于 2017 年，中国总部位于杭州，在北京、上海、深圳、南京、昆 明、重庆设有分支机构；海外研发总部设在斯德哥尔摩，在瑞典、德国、北 美、日本设有分支机构和服务团队。 在全球市场我们服务了 300 多家客户，20+世界五百强合作伙伴。典型客户 有：中国电信、国家电网、上汽大众等。 EMQ X Enterprise 是企业级物联网 MQTT 消息平台，支持千万级物联网设备一 站式接入、MQTT&CoAP 多协议处理、低时延实时消息通信，支持基于 SQL 的内 置规则引擎，灵活处理/转发消息到后端服务，存储消息数据到各种数据库，或 桥接 Kafka、RabbitMQ 等企业中间件。EMQ X Enterprise 适用于各种物联网 应用场景，助企业快速构建物联网应用，并支持公有云、私有云、物理机、容 器/K8S 任意部署。
二、测试目的
在 EMQ X 3.0 版本时我们已做过千万连接和百万消息吞吐的基准测试，那次测 试使用了 20 个 EMQ X 节点的集群，每个节点所在机器为 16 核 32G。 在 4.0 和后续的 4.2，4.3 版本中，我们在架构、内部模块上重新设计和不断优 化，大幅提升了 EMQ X 的性能。本次测试为了展现 EMQ X 4.3 在大规模 MQTT 并 发连接、主题订阅以及高消息吞吐上的能力，被测集群只有 5 个节点，每个节 点所在机器资源为 32 核 64G。
三、测试场景
本次测试使用华为云主机，5 个 EMQ X 节点和测试机在同一个 vpc 中，主要进 行了 1 千万的 MQTT 连接、1 千万的主题订阅加上 QoS 0 百万消息吞吐，和 QoS 1 50 万消息吞吐场景，具体如下所示。（注：如果不做特别说明，所有的连接默认都设置了 300 秒的心跳时间，所有的 消息 payload 均为 50 字节。）
（1）场景一：1000 万 MQTT 连接、订阅+QoS0 广播场景百万消息吞吐
1000 万 MQTT 客户端以每秒 2 万的新增连接速率接入 EMQ X 集群，每个 客户端连接成功后均订阅一个主题，每 10 个连接订阅一个相同的主 题，因此测试达到 100 万主题、1000 万订阅。1000 万连接和订阅完成 后开始进行消息广播场景（接收端数量远大于发送端），50 个 MQTT 连 接作为 pub 客户端发送消息，每 10 个为一组向主题 testn/${__machineName()}/${__threadNum}（n 为 1～5）发送消息， 每个 pub 客户端每秒发送 100 条 QoS 0 消息，1000 个 sub 客户端也分 成 5 组每组 200 个订阅主题 testn/#（n 为 1～5）。 因此，总的消息发布吞吐率为每秒 5000 条，总的消息接收吞吐率达到 每秒 100 万。
（2）场景二：1000 万 MQTT 连接、订阅+QoS0 1 对 1 百万消息吞吐
MQTT 1000 万连接、订阅和上面的场景一相同。1000 万连接和订阅完成 后开始进行 1 对 1 消息收发（接收端数量等于发送端，每个接收端订阅 一个对应的发送端 pub 主题），pub 客户端和 sub 客户端都是 25000 个，每个 pub 客户端每秒发送 20 条 QoS 0 消息，相应的每个 sub 客户 端消费 20 条 QoS 0 消息，因此消息发送和接收均为每秒 50 万条，总的 消息吞吐达到 100 万。
（3）场景三：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 万。
（4）场景四：1000 万 MQTT 连接、订阅+QoS1 50 万 1 对 1 消息吞吐
MQTT 1000 万连接、订阅和上面的场景 1 相同。1000 万连接和订阅完成 后开始进行 QoS 为 1 的 1 对 1 消息收发（接收端数量等于发送端，每 个接收端订阅一个对应的发送端 pub 主题），pub 客户端和 sub 客户端 都是 25000 个，每个 pub 客户端每秒发送 10 条 QoS 1 消息，相应的每 个 sub 客户端消费 10 条 QoS 0 消息，因此消息发送和接收均为每秒 25 万条，总的 QoS 1 消息吞吐达到 50 万。
四、测试结果概述Highlights
（1）场景一：1000 万 MQTT 连接、订阅+QoS0 广播场景百万消息吞吐
平均连接速率达到 2 万/秒，连接+订阅平均响应时间 4.2ms
Sub 平均响应时间 0.33ms
每个节点 EMQ X CPU 平均使用 34%，1 千万客户端全部连接后消息 收发期间每节点 EMQ X CPU 使用范围为 32%～60%
每个节点 EMQ X 内存平均使用 28.4GB，1 千万客户端全部连接后消 息收发期间每节点 EMQ X 内存使用范围为 29GB～35.4 GB
（2）场景二：1000 万 MQTT 连接、订阅+QoS0 1 对 1 百万消息吞吐
平均连接速率达到 2 万/秒，连接+订阅平均响应时间 5ms
sub 平均响应时间 0.3ms
每个节点 EMQ X CPU 平均使用 51%，1 千万客户端全部连接后消息 收发期间每节点 EMQ X CPU 使用范围为 56%～68%
每个节点 EMQ X 内存平均使用 28.7GB，1 千万客户端全部连接后消 息收发期间每节点 EMQ X 内存使用范围为 28.6GB～35.2 GB
（3）场景三：1000 万 MQTT 连接、订阅+ QoS1 广播场景 50 万消息吞吐
平均连接速率达到 2 万/秒，连接+订阅平均响应时间 4.6ms
pub 平均响应时间 1ms，sub 平均响应时间 0.3ms
每个节点 EMQ X CPU 平均使用 38%，1 千万客户端全部连接后消息 收发期间每节点 EMQ X CPU 使用范围为 35%～57%
每个节点 EMQ X 内存平均使用 28.5GB，1 千万客户端全部连接后消 息收发期间每节点 EMQ X 内存使用范围为 29.6GB～33.8GB
（4）场景四：1000 万 MQTT 连接、订阅+QoS1 50 万 1 对 1 消息吞吐
平均连接速率达到 2 万/秒，连接+订阅平均响应时间 4.5ms
pub 平均响应时间 1.1ms，sub 平均响应时间 0.6ms
每个节点 EMQ X CPU 平均使用 48%，1 千万客户端全部连接后消息 收发期间每节点 EMQ X CPU 使用范围为 50%～65%
每个节点 EMQ X 内存平均使用 28.8GB，1 千万客户端全部连接后消 息收发期间每节点 EMQ X 内存使用范围为 30.9GB～36.4GB
五、测试工具
本次测试使用 XMeter 性能测试平台企业版。
XMeter 简介 (https://www.xmeter.net/)：XMeter 是基于开源测试工具 JMeter 扩展的性能测试平台。针对物联网具有的接入规模大、弹性扩展要求、 多种接入协议、混合场景等特点，XMeter 对 JMeter 进行了改造，可以支持大 规模、高并发的性能测试，比如实现千万级别的 MQTT 并发连接和消息吞吐测 试。除了测试 MQTT 协议之外，还可以支持 HTTP/HTTPS 等主流的应用的测 试。
JMeter-MQTT 插件：由 XMeter 实现的开源 MQTT 性能测试插件，在众多的项目 中得到了使用，目前是 JMeter 社区中流行度最高的 MQTT 插件。
工具版本：
XMeter：企业版 3.0
JMeter-MQTT 插件：mqtt-xmeter-2.0.2
JMeter：JMeter5.2.1
六、测试环境及部署
华为云中的测试部署如下所示，本次测试共使用 40 台测试机，其中 20 台每台 模拟 50 万 MQTT 连接，20 台模拟百万 QoS 0 消息吞吐/50 万 QoS 1 消息吞吐。 XMeter 提供的基于 JMeter MQTT 插件的测试工具来模拟业务测试场景； XMeter 内置支持的监控工具用于监控 3 台被测 EMQ X 集群的资源使用情况。
EMQX / XMeter配置：
| 服务 | 数量 | 版本 | 操作系统 | CPU | 内存 | 硬盘 |
| EMQX | 5 | 企业版v4.3.0 | Centos7 | 32核 | 64G | 40G |
| XMeter管理机 | 2 | 企业版v3.0 | Centos7 | 16核 | 32G | 40G |
| XMeter压力机 | 40 | 企业版v3.0 | Centos7 | 16核 | 32G | 40G |
EMQ X 安装成功并加入集群后，使用命令行显示总共安装了 5 个 EMQ X 的节 点。
七、详细测试结果
（1）场景一：1 千万 MQTT 连接、订阅+QoS0 广播场景百万消息吞吐
场景 1 模拟 1000 万 MQTT 客户端以每秒 2 万的新增连接速率接入 EMQ X 集群， 每个客户端连接成功后均订阅一个主题，每 10 个连接订阅一个相同的主题。 1000 万连接和订阅完成后开始进行消息广播场景，50 个 MQTT 连接作为 pub 客 户端发送消息，每 10 个为一组向主题 testn/${__machineName()}/${__threadNum}（n 为 1～5）发送消息，每个 pub 客户端每秒发送 100 条 QoS 0 消息，1000 个 sub 客户端也分成 5 组每组 200 个 订阅主题 testn/#（n 为 1～5）。 测试持续 50 分钟，其中百万消息收发持续 40 分钟。 如下图 EMQ X Dashboard 监控显示，本次测试被测集群共 5 个节点，集群接 入量实际达到 1000 万连接和 1000 万订阅，消息流入（发布）达到每秒 5000 多，消息流出（消费）达到每秒 100 万多。从截图可以看到，每个节点上连接 和订阅均为 200 万。
下图为EMQX集群Dashboard主题监控截图，可以看到主题一共有100万：
XMeter报告：
XMeter报告解析
如上图所示，XMeter 的性能测试报告分成四大部分。后面报告的结果解读方式 类似，如果没有特别之处不再赘述。
概览：这部分是本次测试的汇总信息，这些数值在测试执行时是不断更新 的，反映到目前为止的系统状态，测试结束时数值定格，反映出整个测试 的状况
i.Avg throughput 所有请求平均吞吐量 每秒完成的页面操作请求数(即 throughput，吞吐率)。各类页面由上传的 JMeter 脚本定义，可以是典型的 HTTP 请求，也可以是其它类型的 JMeter 取样器(sampler)。本次测试涉及到 MQTT 连接，MQTT pub 和 MQTT sub。
ii.Avg success throughput 所有请求平均成功吞吐量 每秒完成的验证点成功的页面操作请求数
iii.Avg failed throughput 所有请求平均失败吞吐量
iv.Max virtual user num 最大虚拟用户数 系统曾经达到的最多并发用户数。这个值通常应该等于测试指定的用户 数，除非脚本中有特殊的控制，让一部分用户先于其他用户结束执行。
v.Avg response time(s) 所有请求平均响应时间
vi.Max response time(s) 所有请求最大响应时间
vii.Min response time(s) 所有请求最小请求时间
viii.Response code succ rate 所有请求成功率
ix.Verification point succ rate 所有请求验证点成功率 如果脚本使用了验证点(比如 JMeter 响应断言)，则统计验证点的成功率， 否则这个值等同于响应码成功率。
x.Avg request size(KiB) 所有请求平均大小 所有请求返回内容的平均大小。
图表区域：报告中部的几张图展示了随时间变化的页面响应时间，系统吞 吐量，系统用户数，返回码成功率，网络下载流量的变化趋势。
i.Response time 每个请求响应时间
ii.Throughput 每个请求所有吞吐量
iii. Succ Throughput 每个请求成功吞吐量
iv. Virtual User 虚拟用户数
v. Response code succ rate 响应码成功率
vi. Download bytes 响应数据大小
测试数据明细（Detailed data 表格）：这是报告最后的部分，可以查看 按页面统计的响应时间，吞吐量，请求返回响应的大小，成功率和标准方 差，90 分位响应时间等。
i. Page 请求名称
ii. Hit num 运行次数
iii. Max resp time (s) 最大响应时间
iv. Min resp time (s) 最小响应时间
v. Avg resp time(s) 平均响应时间
vi. Avg throughput 所有平均吞吐量
vii. Avg succ throughput 成功平均吞吐量
viii. Avg failure throughput 失败平均吞吐量
ix. Avg request size(KiB) 平均大小
x. Response code succ rate 响应码成功率
xi. Check point succ rate 验证点成功率
xii. Check point failure 验证点错误数
xiii. Avg deviation 平均标准差 标准方差值越小，说明采样的样本间差异越小，系统表现也越稳 定。
xiv. 90th percentile(s) 90 分位响应时间
xv. Avg 90%(s) 90%平均响应时间 90 分位响应时间和 90%平均响应时间去除了数值最大的 10%响 应时间，在请求响应时间曲线图波动较大的情况下，可以过滤掉 部分数值噪声，以方便对总体响应时间获得更真实的了解。
被测系统监控：XMeter 提供标准的监控报告（ootb-dashboard），展现 的是被监控服务器上操作系统级别的资源使用情况。
i. CPU 使用量图 被监测服务器的总体 CPU 使用量，例如，可以点击 system 和 user 图例，查看处理系统和用户态请求时耗费的 CPU 百分比。 通常 system+user 值高于 80%，我们认为 CPU 资源占用高， 余量不足了。
ii. CPU 负载图 被监测服务器上 CPU 在最近 1,5,15 分钟内的平均负载。这个 平均负载可以粗略地理解为处理器上等待调度运行的任务数，数 值越高说明系统越繁忙。
iii. 内存使用量图 可以关注 free 图线，看内存余量，以及长时间运行可用内存是 否一直减少(有内存泄漏的嫌疑)。
iv. 网络流量图 被监测服务器第一张网卡（eth0)上单位时间的流入流出量 （每 秒多少 KBytes)。 提示：高并发时要确保网络带宽仍有剩余，否 则带宽成为系统瓶颈将妨碍测试更多的并发用户量。 如果您要监视的是其它网卡，可以修改 grafana 的相应查询条件，将 eth0 换成你需要的网络接口名即可。
XMeter 截图所示，pub 和 sub 的吞吐量都非常稳定，sub 吞吐稳定在 100 万， 与 EMQ X Dashboard 显示一致。所有响应都成功，平均响应时间毫秒级。篇 幅所限报告只截取了 EMQ X 集群中的两个节点的资源监控，消息吞吐期间 32 核的 CPU idle 在 25%到 55%之间，64G 的内存 free 在 24G 左右，这些指标 表明 EMQ X 在该压力下表现健康稳定。
（2）场景二：1 千万 MQTT 连接、订阅+QoS0 1 对 1 百万消息吞吐
场景 2 模拟的 MQTT 1000 万连接、订阅和上面的场景一相同。1000 万连接和订 阅完成后开始进行 1 对 1 消息收发（接收端数量等于发送端，每个接收端订阅 一个对应的发送端 pub 主题），pub 客户端和 sub 客户端都是 25000 个，每个 pub 客户端每秒发送 20 条 QoS 0 消息，相应的每个 sub 客户端消费 20 条 QoS 0 消息。 测试持续 50 分钟，其中百万消息收发持续 40 分钟。 如下图 EMQ X Dashboard 监控显示，本次测试被测集群共 5 个节点，集群接 入量实际达到 1000 万连接和 1000 万订阅，消息流入（发布）消息流出（消 费）都达到了每秒 50 万。从截图可以看到，每个节点上连接和订阅均为 200 万。
下图为 EMQ X 集群 Dashboard 主题监控截图，可以看到主题一共有 100 万:
XMeter报告
如上 XMeter 截图所示，pub 和 sub 的吞吐量都稳定在 50 万，与 EMQ X Dashboard 显示一致。所有响应都成功，平均响应时间毫秒级。篇幅所限报告只截取了 EMQ X 集群中的一个节点的资源监控，消息吞吐期间 32 核的 CPU idle 在 20%左右，64G 的内存 free 在 24G 左右，这些指标表明 EMQ X 在该压 力下表现健康稳定。
（3）场景三：1 千万 MQTT 连接、订阅+QoS1 广播场景 50 万消息吞吐
场景 3 模拟的 MQTT 1000 万连接、订阅和上面的场景相同。1000 万连接和订阅 完成后开始进行消息广播场景，50 个 MQTT 连接作为 pub 客户端发送消息，每 10 个为一组向主题 testn/${__machineName()}/${__threadNum}（n 为 1～5） 发送消息，每个 pub 客户端每秒发送 50 条 QoS 0 消息，1000 个 sub 客户端也 分成 5 组每组 200 个订阅主题 testn/#（n 为 1～5）。
测试持续 50 分钟，其中 50 万消息收发持续 40 分钟。
如下图 EMQ X Dashboard 监控显示，本次测试被测集群共 5 个节点，集群接 入量实际达到 1000 万连接和 1000 万订阅，消息流出（消费）达到了每秒 50 万多。从截图可以看到，每个节点上连接和订阅均为 200 万。
下图为 EMQ X 集群其中一个节点的消息统计，可以看到场景 3 的消息 qos 是 1，发出的消息数量是接收到的 200 倍，消息没有任何丢弃。
下图为 EMQ X 集群 Dashboard 主题监控截图，可以看到主题一共有 100 万：
XMeter报告
如上 XMeter 截图所示，sub 的吞吐稳定在 50 万，与 EMQ X Dashboard 显示 一致。所有响应都成功，平均响应时间毫秒级。篇幅所限报告只截取了 EMQ X 集群中的一个节点的资源监控，消息吞吐期间 32 核的 CPU idle 在 30%到 50% 之间，64G 的内存 free 在 25G 左右，这些指标表明 EMQ X 在该压力下表现健 康稳定。
（4）场景四：1 千万 MQTT 连接、订阅+QoS1 50 万 1 对 1 消息吞吐
场景 4 模拟的 MQTT 1000 万连接、订阅和上面的场景相同。1000 万连接和订阅 完成后开始进行 1 对 1 消息收发（接收端数量等于发送端，每个接收端订阅一 个对应的发送端 pub 主题），pub 客户端和 sub 客户端都是 25000 个，每个 pub 客户端每秒发送 10 条 QoS 1 消息，相应的每个 sub 客户端消费 10 条 QoS 1 消 息。
测试持续 50 分钟，其中 50 万消息收发持续 40 分钟。
如下图 EMQ X Dashboard 监控显示，本次测试被测集群共 5 个节点，集群接 入量实际达到 1000 万连接和 1000 万订阅，消息流入（发布）消息流出（消 费）都达到了每秒 25 万。从截图可以看到，每个节点上连接和订阅均为 200 万。
下图为 EMQ X 集群 Dashboard 主题监控截图，可以看到主题一共有 100 万：
XMeter 报告
如上 XMeter 截图所示，pub 和 sub 的吞吐量都稳定在 25 万，与 EMQ X Dashboard 显示一致。所有响应都成功，平均响应时间毫秒级。篇幅所限报告 只截取了 EMQ X 集群中的一个节点的资源监控，消息吞吐期间 32 核的 CPU idle 在 20%左右，64G 的内存 free 在 24G 左右，这些指标表明 EMQ X 在该压 力下表现健康稳定。
附录 1 系统调优
参考：https://docs.emqx.io/enterprise/latest/cn/tutorial/tune.html
附录 2 测试工具试用、下载地址
• XMeter 官网和试用地址：https://www.xmeter.net/
• XMeter MQTT 插件下载：https://github.com/xmeter-net/mqtt-jmeter
• JMeter 下载地址：https://jmeter.apache.org