压测报告
2025年3月3日大约 3 分钟
一、机器准备
准备两台服务器,一台为部署fastbee服务端应用,另一台为客户端压力机。其中:
- Fastbee服务器(1台)
- 系统:TencentOS Server 2.4 (TK4)
- CPU:4C
- 内存:16GB
- 带宽:15Mbps
- MQTT Broker 服务端:EMQX 5.7.2
- 压力机(1台)
- 系统:OpenCloudOS 8 (腾讯云轻量应用服务器)
- CPU:4C
- 内存:8GB
- 峰值带宽:200Mbps
- 压力机测试工具:emqtt-bench-0.4.18-el7-amd64.tar.gz
二、压测步骤
- 拉取压测分支代码(dev-yace),编译jar包并运行
- 创建脚本规则,修改发布的消息内容
import cn.hutool.json.JSONArray;
import cn.hutool.json.JSONObject;
import cn.hutool.json.JSONUtil;
import cn.hutool.core.util.NumberUtil;
// 1. 获取主题和内容(必要)
String sysPayload = "";
// 2. 数据转换(自己处理)
JSONArray newArray = new JSONArray();
JSONObject newObject = new JSONObject();
newObject.put("id","temperature");
newObject.put("value","18");
newArray.add(newObject);
sysPayload = newArray.toString();
// 3. 返回新的数据(必要)
msgContext.setSerialNumber("D1ELV3A5TOJS");
msgContext.setPayload(sysPayload);
- 优化系统调优
- 服务端:
// 修改系统参数,扩大可用端口范围
sudo sysctl -w net.ipv4.ip_local_port_range="1025 65534"
// 系统全局允许分配的最大文件句柄数
sudo sysctl -w fs.file-max=2097152
sudo sysctl -w fs.nr_open=2097152
sudo echo 2097152 > /proc/sys/fs/nr_open
// 允许当前会话 / 进程打开文件句柄数
sudo ulimit -n 1048576
// 允许复用处于 `TIME_WAIT` 状态的端口
sudo sysctl -w net.ipv4.tcp_tw_reuse=1
- 压测机:
// 测试客户端服务器在一个接口上,最多只能创建 65000 连接
sysctl -w net.ipv4.ip_local_port_range="500 65535"
echo 1000000 > /proc/sys/fs/nr_open
ulimit -n 100000
- 执行压测命令
// 消息发布命令
// 20k客户端连接 3300毫秒发送一个1字节数据 起始客户端为1000个(20k连接 6k QPS)
./emqtt_bench pub -t /41/D1ELV3A5TOJS/property/post -h 1.14.207.123 -s 1 -q 0 -c 20000 -I 3300 -n 1000
// 纯连接命令
./emqtt_bench conn -h 1.14.207.123 -p 1884 -u sunrain -P sunrain -c 60000 -i 10
三、压测结果
场景一:20k客户端连接 5000毫秒发送一个1字节数据 4kqps
最终测试结果如下:
场景二:20k客户端连接 3300毫秒发送一个1字节数据 6kqps
最终测试结果如下:
场景三:20k客户端连接 3300毫秒发送一个1字节数据 6kqps
同时增加了10个订阅端,cpu资源不受限的情况下测试,8c和16c 最终测试结果如下:
- 8c:
- 16c:
四、压测总结
- 单机版本能稳定运行的推荐配置为:cpu:8c 内存:16G 带宽:10Mbps, 性能可达:20k客户端连接 4-6kqps
- 在推荐配置下,20k-30k客户端的连接能满足,稳定的qps处理能力在:4k-6k,如果系统要求超过这个性能要求可以考虑集群版本
- 推荐替换性能好点的mqtt客户端:mica-mqtt,paho-mqtt在高并发下有断连的风险,会丢失数据。
- 设备有高频的发布属性消息的需求时,可以分离订阅和发布内置mqtt客户端,减少消息的阻塞,提高连接稳定性。