性能工具之emqtt-bench BenchMark 测试示例

简介: 【4月更文挑战第19天】在前面两篇文章中介绍了emqtt-bench工具和MQTT的入门压测,本文示例 emqtt_bench 对 MQTT Broker 做 Beachmark 测试,让大家对 MQTT消息中间 BenchMark 测试有个整体了解,方便平常在压测工作查阅。

一、前言

在前面两篇文章中介绍了emqtt-bench工具和MQTT的入门压测,本文示例 emqtt_bench 对 MQTT Broker 做 Beachmark 测试,让大家对 MQTT消息中间 BenchMark 测试有个整体了解,方便平常在压测工作查阅。

BenchMark 测试以 MQTT 最典型的场景来验证其性能:

  • 并发连接:使用 emqtt-bench 创建海量连接到 MQTT Broker。
  • 消息吞吐量测试:使用 emqtt-bench 在 EMQX 中创建出海量的 Qos0 消息吞吐量,分别模拟发布-订阅 1对1,1对多,多对1这 3 种类型场景。

三、机器准备

共需准备六台服务器,一台为 EMQX Broker,七台为客户端压力机。其中:

EMQX Broker(1台):

  • 系统:CentOS Linux release 7.6.1810 (Core)
  • CPU:8C
  • 内存:8GB
  • 服务端:EMQX 5.1.6
  • 压力机:emqtt-bench-0.4.18-el7-amd64.tar.gz

压力机(6台):

  • 系统:CentOS Linux release 7.6.1810 (Core)
  • CPU:8C
  • 内存:16GB
  • 压力机:emqtt-bench-0.4.18-el7-amd64.tar.gz

四、典型压测场景

1、并发连接

  • 场景名称:MQTT Broker 单节点支持 30 万级设备在线,背景连接 (只连接不发送消息)
  • 描述:模拟 30 万 MQTT TCP 并发连接,并保持在线,测试执行 1 个小时。
  • 期望结果:内网测试成功率为 100%,无连接掉线,CPU 和内存在测试期间表现平稳,没有大幅度的抖动。

拓扑结构如下:
image.png

在6台客户端压力机上同时执行该命令,在每台压力机上启动 5w 的连接数,共计 30w 的连接:

./emqtt_bench conn -h emqx-server -c 50000

客户端压力机执行截图:
image.png

EMQX Broker运行情况:
image.png

在 MQTT Broker 单节点 8C8G的情况,我压到的峰值是30W连接,超过会导致服务崩溃。

2、消息吞吐量测试

注意这里我只具体说明如何设置,并不是实际压测场景数据。

2.1 1 对 1(示例)

  • 场景名称:MQTT Broker 单节点 500 并发连接下支持1000 QoS0 消息吞吐
  • 描述:1000 MQTT TCP 连接, pub 客户端和 sub 客户端数量相同都是 500,每个接收端均订阅一个对应的发送端 pub 主题,每个 pub 客户端每秒发送 2 条 QoS 0、payload 为 256 字节(默认值)的消息。因此消息发送和接收均为每秒 1000,总的消息吞吐达到每秒 2000。测试执行 1 个小时。
  • 期望结果:内网测试成功率为 100%,无消息积压,CPU 和内存在测试期间表现平稳,没有大幅度的抖动。

拓扑结构如下:

image.png

单台sub 客户端压力机:

./emqtt_bench sub -t test_topic_%i -h emqx-server -c 500

参数说明:

  • -s:消息 Payload 的大小;单位:字节。不加默认256字节。
  • -t:topic,%i:表示客户端的序列数
  • -h:要连接的 MQTT 服务器地址
  • -c:客户端总数
[root@ bin]# ./emqtt_bench sub -t test_topic_%i -h emqx-server -c 500
Start with 8 workers, addrs pool size: 1 and req interval: 80 ms 

1s sub total=104 rate=103.28/sec
1s connect_succ total=104 rate=103.28/sec
2s sub total=200 rate=96.00/sec
2s connect_succ total=200 rate=96.00/sec
3s sub total=296 rate=96.00/sec
3s connect_succ total=296 rate=96.00/sec
4s sub total=400 rate=104.00/sec
4s connect_succ total=400 rate=104.00/sec
5s sub total=496 rate=96.00/sec
5s connect_succ total=496 rate=96.00/sec
6s sub total=500 rate=4.00/sec
6s connect_succ total=500 rate=4.00/sec

单台 pub 客户端压力机:

./emqtt_bench pub -t test_topic/%i -h  emqx-server -c 500 -I 500

参数说明:

  • -s:消息 Payload 的大小;单位:字节。不加默认256字节。
  • -t:topic,%i:表示客户端的序列数
  • -h:要连接的 MQTT 服务器地址
  • -c:客户端总数
  • -I:每间隔多少时间创建一个客户端;单位:毫秒
[root@ bin]# ./emqtt_bench pub -t test_topic/%i -h  emqx-server -c 500 -I 500
Start with 8 workers, addrs pool size: 1 and req interval: 80 ms 

1s pub total=160 rate=159.05/sec
1s connect_succ total=104 rate=103.38/sec
2s pub total=512 rate=352.00/sec
2s connect_succ total=200 rate=96.00/sec
3s pub total=1056 rate=544.00/sec
3s connect_succ total=296 rate=96.00/sec
4s pub total=1808 rate=752.00/sec
4s connect_succ total=400 rate=104.00/sec
5s pub total=2752 rate=944.00/sec
5s connect_succ total=496 rate=96.00/sec
6s pub total=3752 rate=1000.00/sec
6s connect_succ total=500 rate=4.00/sec
7s pub total=4752 rate=1000.00/sec
8s pub total=5752 rate=1000.00/sec
9s pub total=6752 rate=1000.00/sec
10s pub total=7752 rate=1000.00/sec
11s pub total=8752 rate=1000.00/sec
12s pub total=9752 rate=1000.00/sec
13s pub total=10752 rate=1000.00/sec
14s pub total=11752 rate=1000.00/sec

在订阅客户端压力机,可看到当前接收消息的速率,类似于:

12s pub total=9752 rate=1000.00/sec

MQTT Broker 运行情况:
image.png

2.2 多对1(示例)

  • 场景名称:并发连接+消息吞吐(上报)
  • 描述:501 MQTT TCP 连接, pub 客户端 500 和 sub 客户端1,接收端均订阅同一个主题,每个 pub 客户端每秒发送 2 条 QoS 0、payload 为 256 字节的消息。因此消息发送和接受均为每秒 1000,总的消息吞吐达到每秒 2000。测试执行 1 个小时。
  • 期望结果:内网测试成功率为 100%,无消息积压,CPU 和内存在测试期间表现平稳,没有大幅度的抖动。

拓扑结构如下:
在这里插入图片描述

单台 sub 客户端压力机:

./emqtt_bench sub -t test_topic -h emqx-server -c 1

参数说明:

  • -s:消息 Payload 的大小;单位:字节。不加默认256字节。
  • -t:topic,%i:表示客户端的序列数
  • -h:要连接的 MQTT 服务器地址
  • -c:客户端总数
[root@ bin]# ./emqtt_bench sub -t test_topic -h emqx-server -c 1
Start with 8 workers, addrs pool size: 1 and req interval: 80 ms 

1s sub total=1 rate=0.99/sec
1s connect_succ total=1 rate=0.99/sec

单台 pub 客户端压力机:

./emqtt_bench pub -t test_topic -h  emqx-server -c 500 -I 500

参数说明:

  • -s:消息 Payload 的大小;单位:字节。不加默认256字节。
  • -t:topic,%i:表示客户端的序列数
  • -h:要连接的 MQTT 服务器地址
  • -c:客户端总数
  • -I:每间隔多少时间创建一个客户端;单位:毫秒
root@bin]# ./emqtt_bench pub -t test_topic -h  emqx-server -c 500 -I 500
Start with 8 workers, addrs pool size: 1 and req interval: 80 ms 

1s pub total=160 rate=158.89/sec
1s connect_succ total=104 rate=103.28/sec
2s pub total=496 rate=336.00/sec
2s connect_succ total=184 rate=80.00/sec
3s pub total=1040 rate=544.00/sec
3s connect_succ total=296 rate=112.00/sec
4s pub total=1792 rate=752.00/sec
4s connect_succ total=400 rate=104.00/sec
5s pub total=2736 rate=944.00/sec
5s connect_succ total=496 rate=96.00/sec
6s pub total=3736 rate=1000.00/sec
6s connect_succ total=500 rate=4.00/sec
7s pub total=4736 rate=1000.00/sec
8s pub total=5736 rate=1000.00/sec
9s pub total=6736 rate=1000.00/sec
10s pub total=7736 rate=1000.00/sec
11s pub total=8736 rate=1000.00/sec
12s pub total=9736 rate=1000.00/sec
13s pub total=10736 rate=1000.00/sec
14s pub total=11736 rate=1000.00/sec
15s pub total=12736 rate=1000.00/sec
16s pub total=13736 rate=1000.00/sec
17s pub total=14736 rate=1000.00/sec

MQTT Broker 运行情况(举例):
image.png

2.3 1对多(示例)

  • 场景名称:消息广播
  • 描述:501 MQTT TCP 连接, pub 客户端 1 和 sub 客户端 500,接收端均订阅同一个主题,pub 客户端每秒发送 2 条 QoS 0、payload 为 256 字节的消息。因此消息发送为每秒 2,消息接收为每秒 1000,总的消息吞吐达到每秒 1002。测试执行 1 个小时。
  • 期望结果:内网测试成功率为 100%,无消息积压,CPU 和内存在测试期间表现平稳,没有大幅度的抖动。

拓扑结构如下:
image.png

单台 sub 客户端压力机:

./emqtt_bench sub -t test_topic -h emqx-server -c 500

参数说明:

  • -s:消息 Payload 的大小;单位:字节。不加默认256字节。
  • -t:topic,%i:表示客户端的序列数
  • -h:要连接的 MQTT 服务器地址
  • -c:客户端总数
[root@d bin]# ./emqtt_bench sub -t test_topic -h emqx-server -c 500
Start with 8 workers, addrs pool size: 1 and req interval: 80 ms 

1s sub total=104 rate=103.38/sec
1s connect_succ total=104 rate=103.38/sec
2s sub total=200 rate=96.00/sec
2s connect_succ total=200 rate=96.00/sec
3s sub total=296 rate=96.00/sec
3s connect_succ total=296 rate=96.00/sec
4s sub total=400 rate=104.00/sec
4s connect_succ total=400 rate=104.00/sec
5s sub total=496 rate=96.00/sec
5s connect_succ total=496 rate=96.00/sec
6s sub total=500 rate=4.00/sec
6s connect_succ total=500 rate=4.00/sec

单台 pub 客户端压力机:

./emqtt_bench pub -t test_topic -h  emqx-server -c 1 -I 500

参数说明:

  • -s:消息 Payload 的大小;单位:字节。不加默认256字节。
  • -t:topic,%i:表示客户端的序列数
  • -h:要连接的 MQTT 服务器地址
  • -c:客户端总数
  • -I:每间隔多少时间创建一个客户端;单位:毫秒
[root@ bin]# ./emqtt_bench pub -t test_topic -h  emqx-server -c 1 -I 500
Start with 8 workers, addrs pool size: 1 and req interval: 80 ms 

1s pub total=2 rate=1.99/sec
1s connect_succ total=1 rate=0.99/sec
2s pub total=4 rate=2.00/sec
3s pub total=6 rate=2.00/sec
4s pub total=8 rate=2.00/sec
5s pub total=10 rate=2.00/sec
6s pub total=12 rate=2.00/sec
7s pub total=14 rate=2.00/sec
8s pub total=16 rate=2.00/sec
9s pub total=18 rate=2.00/sec
10s pub total=20 rate=2.00/sec
11s pub total=22 rate=2.00/sec
12s pub total=24 rate=2.00/sec
13s pub total=26 rate=2.00/sec
14s pub total=28 rate=2.00/sec
15s pub total=30 rate=2.00/sec
16s pub total=32 rate=2.00/sec
17s pub total=34 rate=2.00/sec

EMQX Broker 运行情况(举例):
image.png

五、遇到的问题

client(): EXIT for {shutdown,eaddrnotavail}

在压力机连接超过5万的时候,出现了emqtt_bench客户端报错的情况。

EMQX Broker 运行情况:

image.png

单台客户端压力机报错截图:
image.png

通过设置以下内核参数解决:

#允许当前会话 / 进程打开文件句柄数:
ulimit -n 1048576

# 可用端口范围:
sudo sysctl -w net.ipv4.ip_local_port_range="1025 65534"

原因分析:
Linux 内核在这个范围内选择一个可用的端口作为本地端口去connect服务器,如果没有可用的端口可用,比如这个范围内的端口都处于如下状态中的一种:

  1. bind使用的端口
  2. 端口处于非TIME_WAIT状态
  3. 端口处于TIME_WAIT状态,但是没有启用tcp_tw_reuse,那么就会返回EADDRNOTAVAIL错误。

一般情况下,出现这个错误可用使用如下方法解决问题:

  1. 增大可选端口的范围,修改/proc/sys/net/ipv4/ip_local_port_range的值。
  2. 开启tcp_tw_reuse,允许使用TIME_WAIT状态的端口。

六、附录:调优建议

当然,我们也可以在 Beachmark 测试前就做好服务器参数调优,可以参考以下的内容。

1、关闭交换分区

Linux 交换分区可能会导致 EMQX Broker 出现不确定的内存延迟,影响系统的稳定性。 建议永久关闭交换分区。

  • 要立即关闭交换分区,执行命令 sudo swapoff -a。
  • 要永久关闭交换分区,在 /etc/fstab 文件中注释掉 swap 行,然后重新启动主机。

2、Linux 操作系统参数

系统全局允许分配的最大文件句柄数:

sysctl -w fs.file-max=2097152
sysctl -w fs.nr_open=2097152
echo 2097152 > /proc/sys/fs/nr_open

允许当前会话 / 进程打开文件句柄数:

ulimit -n 1048576

/etc/sysctl.conf

持久化 fs.file-max 设置到 /etc/sysctl.conf 文件:

fs.file-max = 1048576

/etc/systemd/system.conf 设置服务最大文件句柄数:

DefaultLimitNOFILE=1048576

/etc/security/limits.conf

/etc/security/limits.conf 持久化设置允许用户 / 进程打开文件句柄数:

*      soft   nofile      1048576
*      hard   nofile      1048576

3、TCP 协议栈网络参数

并发连接 backlog 设置:

sysctl -w net.core.somaxconn=32768
sysctl -w net.ipv4.tcp_max_syn_backlog=16384
sysctl -w net.core.netdev_max_backlog=16384

可用端口范围:

sysctl -w net.ipv4.ip_local_port_range='1024 65535'

TCP Socket 读写 Buffer 设置:

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'

TCP 连接追踪设置:

sysctl -w net.nf_conntrack_max=1000000
sysctl -w net.netfilter.nf_conntrack_max=1000000
sysctl -w net.netfilter.nf_conntrack_tcp_timeout_time_wait=30

TIME-WAIT Socket 最大数量、回收与重用设置:

sysctl -w net.ipv4.tcp_max_tw_buckets=1048576

# 注意:不建议开启該设置,NAT 模式下可能引起连接 RST
# sysctl -w net.ipv4.tcp_tw_recycle=1
# sysctl -w net.ipv4.tcp_tw_reuse=1

FIN-WAIT-2 Socket 超时设置:

sysctl -w net.ipv4.tcp_fin_timeout=15

3、测试客户端设置

测试客户端服务器在一个接口上,最多只能创建 65000 连接:

# 可用端口范围:
sysctl -w net.ipv4.ip_local_port_range="500 65535"

#允许当前会话 / 进程打开文件句柄数:
echo 1048576 > /proc/sys/fs/nr_open
ulimit -n 1048576

参考资料:

相关实践学习
消息队列RocketMQ版:基础消息收发功能体验
本实验场景介绍消息队列RocketMQ版的基础消息收发功能,涵盖实例创建、Topic、Group资源创建以及消息收发体验等基础功能模块。
消息队列 MNS 入门课程
1、消息队列MNS简介 本节课介绍消息队列的MNS的基础概念 2、消息队列MNS特性 本节课介绍消息队列的MNS的主要特性 3、MNS的最佳实践及场景应用 本节课介绍消息队列的MNS的最佳实践及场景应用案例 4、手把手系列:消息队列MNS实操讲 本节课介绍消息队列的MNS的实际操作演示 5、动手实验:基于MNS,0基础轻松构建 Web Client 本节课带您一起基于MNS,0基础轻松构建 Web Client
目录
相关文章
|
4天前
|
安全 前端开发 测试技术
如何选择合适的自动化安全测试工具
选择合适的自动化安全测试工具需考虑多个因素,包括项目需求、测试目标、系统类型和技术栈,工具的功能特性、市场评价、成本和许可,以及集成性、误报率、社区支持、易用性和安全性。综合评估这些因素,可确保所选工具满足项目需求和团队能力。
|
2天前
|
监控 网络协议 Java
一些适合性能测试脚本编写和维护的工具
一些适合性能测试脚本编写和维护的工具
|
3天前
|
安全 网络协议 关系型数据库
最好用的17个渗透测试工具
渗透测试是安全人员为防止恶意黑客利用系统漏洞而进行的操作。本文介绍了17款业内常用的渗透测试工具,涵盖网络发现、无线评估、Web应用测试、SQL注入等多个领域,包括Nmap、Aircrack-ng、Burp Suite、OWASP ZAP等,既有免费开源工具,也有付费专业软件,适用于不同需求的安全专家。
8 2
|
14天前
|
Web App开发 定位技术 iOS开发
Playwright 是一个强大的工具,用于在各种浏览器上测试应用,并模拟真实设备如手机和平板。通过配置 `playwright.devices`,可以轻松模拟不同设备的用户代理、屏幕尺寸、视口等特性。此外,Playwright 还支持模拟地理位置、区域设置、时区、权限(如通知)和配色方案,使测试更加全面和真实。例如,可以在配置文件中设置全局的区域设置和时区,然后在特定测试中进行覆盖。同时,还可以动态更改地理位置和媒体类型,以适应不同的测试需求。
Playwright 是一个强大的工具,用于在各种浏览器上测试应用,并模拟真实设备如手机和平板。通过配置 `playwright.devices`,可以轻松模拟不同设备的用户代理、屏幕尺寸、视口等特性。此外,Playwright 还支持模拟地理位置、区域设置、时区、权限(如通知)和配色方案,使测试更加全面和真实。例如,可以在配置文件中设置全局的区域设置和时区,然后在特定测试中进行覆盖。同时,还可以动态更改地理位置和媒体类型,以适应不同的测试需求。
17 1
|
29天前
|
jenkins 测试技术 持续交付
提升软件测试效率的实用技巧与工具
【10月更文挑战第12天】 本文将深入探讨如何通过优化测试流程、引入自动化工具和持续集成等策略,来显著提高软件测试的效率。我们将分享一些实用的技巧和工具,帮助测试人员更高效地发现和定位问题,确保软件质量。
44 2
|
28天前
|
测试技术 PHP 开发工具
php性能监测模块XHProf安装与测试
【10月更文挑战第13天】php性能监测模块XHProf安装与测试
28 0
|
5天前
|
JSON Java 测试技术
SpringCloud2023实战之接口服务测试工具SpringBootTest
SpringBootTest同时集成了JUnit Jupiter、AssertJ、Hamcrest测试辅助库,使得更容易编写但愿测试代码。
29 3
|
1月前
|
JSON 算法 数据可视化
测试专项笔记(一): 通过算法能力接口返回的检测结果完成相关指标的计算(目标检测)
这篇文章是关于如何通过算法接口返回的目标检测结果来计算性能指标的笔记。它涵盖了任务描述、指标分析(包括TP、FP、FN、TN、精准率和召回率),接口处理,数据集处理,以及如何使用实用工具进行文件操作和数据可视化。文章还提供了一些Python代码示例,用于处理图像文件、转换数据格式以及计算目标检测的性能指标。
56 0
测试专项笔记(一): 通过算法能力接口返回的检测结果完成相关指标的计算(目标检测)
|
2月前
|
移动开发 JSON Java
Jmeter实现WebSocket协议的接口测试方法
WebSocket协议是HTML5的一种新协议,实现了浏览器与服务器之间的全双工通信。通过简单的握手动作,双方可直接传输数据。其优势包括极小的头部开销和服务器推送功能。使用JMeter进行WebSocket接口和性能测试时,需安装特定插件并配置相关参数,如服务器地址、端口号等,还可通过CSV文件实现参数化,以满足不同测试需求。
230 7
Jmeter实现WebSocket协议的接口测试方法
|
2月前
|
JSON 移动开发 监控
快速上手|HTTP 接口功能自动化测试
HTTP接口功能测试对于确保Web应用和H5应用的数据正确性至关重要。这类测试主要针对后台HTTP接口,通过构造不同参数输入值并获取JSON格式的输出结果来进行验证。HTTP协议基于TCP连接,包括请求与响应模式。请求由请求行、消息报头和请求正文组成,响应则包含状态行、消息报头及响应正文。常用的请求方法有GET、POST等,而响应状态码如2xx代表成功。测试过程使用Python语言和pycurl模块调用接口,并通过断言机制比对实际与预期结果,确保功能正确性。
242 3
快速上手|HTTP 接口功能自动化测试

热门文章

最新文章