一、测试目的

测试 EMQ X 企业版 4.3.6 单节点 10 万并发连接下支持 20 万 QoS1 消息吞吐所需 EMQ X 资源及响应时间等性能指标。

二、测试架构

三、测试环境、机器配置及测试工具

• 测试环境：华为云北京四区VPC

• 测试工具：XMeter企业版v3.2.0

  EMQX、测试机配置：

  服务	数量	版本	操作系统	CPU	内存	云主机型号
  EMQX	1	4.3.6	Centos7.8	32核	64G	C6.8xlarge2
  XMeter管理机	2	3.2.0	Centos7.8	8核	16G	C6.8xlarge2
  XMeter压力机	10	/	Centos7.8	8核	16G	C6.8xlarge2

四、测试场景

本次测试场景为 1 对 1 消息吞吐，具体为：10 万 MQTT TCP 连接， pub 客户端 和 sub 客户端数量相同都是 5 万，每个接收端均订阅一个对应的发送端 pub 主 题，每个 pub 客户端每秒发送 2 条 QoS 1、payload 为 1k 字节的消息。因此消 息发送和接收均为每秒 10 万，总的消息吞吐达到每秒 20 万。测试执行 1 个小 时。 为了比较在相同场景下不同 payload 大小对于 EMQ X 资源消耗的影响，还测试 了 payload 为 200 字节的场景。

五、测试结果

具体测试结果及 EMQ X 资源使用截图如下：

• EMQX Dashboard统计：

  
  

• EMQX Dashboard消息数统计：

  

  测试结束从 Dashboard 的消息统计可以看到 QoS 1 的消息收发一致（根据 MQTT 协议规范，QoS1 的消息是至少发送一次 at least once，在 1 小时的压力测试 下 3 亿多条消息中有几条由于 PUBACK 丢失或没有及时收到导致重复发送是正 常的）。
  

• EMQX节点资源使用：

  payload=1KB

  

  payload=200B

  
  

• XMeter测试报告截图：

  

  

  

六、测试总结

如以上结果所示，EMQ X 32C64G 配置下可以支持 10 万连接、20 万 1 对 1 QoS 1、payload 为 1kB 的消息吞吐场景（发布和接收均为每秒 10 万）。 payload 为 1kB 时，消息吞吐期间，EMQ X 所在机器 CPU user 使用范围 50% ～ 58%，平均使用 54%，CPU idle 范围 16%～22%，平均 20%。内存使用 稳定，used 在 6.4G 到 9G。 payload 为 200B 时，消息吞吐期间，EMQ X 所在机器 CPU user 使用范围 49% ～ 58%，平均使用 54%，CPU idle 范围 17%～23%，平均 20%。内存使用 稳定，used 在 6.3G 到 8G。 内网测试 pub 和 sub 的平均响应时间均在毫秒级。 从以上数据可以看到在相同场景下，payload 200 字节和 1k 字节对于 EMQ  X 资源的消耗和性能没有区别。

附录1:操作系统调优

可参考 https://docs.emqx.io/enterprise/latest/cn/tutorial/tune.html， 亦可直接 sh 附录 3 中的调优脚本 sys_tune.sh。

附录2:测试工具使用、下载地址

XMeter 简介 (https://www.xmeter.net/)：XMeter 是基于开源测试工具 JMeter 扩展的性能测试平台。针对物联网具有的接入规模大、弹性扩展要求、 多种接入协议、混合场景等特点，XMeter 对 JMeter 进行了改造，实现了百万 级别并发测试支持，并对测试数据进行实时处理并图形化展示。 

• XMeter 官网和试用地址：https://www.xmeter.net/

• XMeter MQTT 插件下载：https://github.com/xmeter-net/mqtt-jmeter 

• JMeter 下载地址：https://jmeter.apache.org

附录3:系统调优脚本

#!/bin/sh 

## Linux Kernel Tuning 
sysctl -w fs.file-max=2097152 
sysctl -w fs.nr_open=2097152 
echo 2097152 > /proc/sys/fs/nr_open 
echo 2097152 > /proc/sys/fs/file-max 

## The limit on opened file handles for current session 
ulimit -n 1048576 

## Add the ‘fs.file-max’ to /etc/sysctl.conf, make the changes permanent 
## /etc/security/limits.conf 
##  
##  
## * soft nofile 1048576 
## * hard nofile 1048576 

cat <<- 'EOF' >> /etc/security/limits.conf 
* soft nofile 1048576 
* hard nofile 1048576 
EOF 

## Network Tuning 
## Increase number of incoming connections backlog 
sysctl -w net.core.somaxconn=32768 
sysctl -w net.ipv4.tcp_max_syn_backlog=16384 
sysctl -w net.core.netdev_max_backlog=16384 

## Local Port Range: 
sysctl -w net.ipv4.ip_local_port_range=1000 65535 

## Read/Write Buffer for TCP connections: 
sysctl -w net.core.rmem_default=262144 
sysctl -w net.core.wmem_default=262144 
sysctl -w net.core.rmem_max=16777216 
sysctl -w net.core.wmem_max=16777216 
sysctl -w net.core.optmem_max=16777216 
sysctl -w net.ipv4.tcp_rmem=1024 4096 16777216
sysctl -w net.ipv4.tcp_wmem=1024 4096 16777216 

## Timeout for FIN-WAIT-2 sockets: 
sysctl -w net.ipv4.tcp_fin_timeout=15 

cat <<- 'EOF' >> /etc/sysctl.conf 
net.core.somaxconn=32768 
net.ipv4.tcp_max_syn_backlog=16384 
net.core.netdev_max_backlog=16384 
net.ipv4.ip_local_port_range=1000 65535 
net.core.rmem_default=262144 
net.core.wmem_default=262144 
net.core.rmem_max=16777216 
net.core.wmem_max=16777216 
net.core.optmem_max=16777216 
net.ipv4.tcp_rmem=1024 4096 16777216 
net.ipv4.tcp_wmem=1024 4096 16777216 
net.ipv4.tcp_max_tw_buckets=1048576 
net.ipv4.tcp_fin_timeout=15 
EOF