如何入门做物联网系统压测？

文章目录

一、政策解读
二、MQTT 压测常见场景
三、MQTT常见业务场景
- 1、并发连接
- 2、消息吞吐量测试
- - 2.1 1 对 1
  - 2.2 多对1（上报）
  - 2.3 1对多
  - 2.4 其它场景
三、MQTT常见性能指标
四、MQTT常见性能工具
- 1、emqtt-bench
- 2、JMeter
五、小结

一、政策解读

微信公众号“工信微报”4月9日消息，工业和信息化部、国家发展改革委、财政部、中国人民银行、税务总局、市场监管总局、金融监管总局等七部门近日联合印发 《推动工业领域设备更新实施方案》，提出到 2027 年，工业领域设备投资规模较 2023 年增长 25 %以上，规模以上工业企业数字化研发设计工具普及率、关键工序数控化率分别超过 90 %、75 %，工业大省大市和重点园区规上工业企业数字化改造全覆盖，重点行业能效基准水平以下产能基本退出、主要用能设备能效基本达到节能水平，本质安全水平明显提升，创新产品加快推广应用，先进产能比重持续提高。

在这里插入图片描述

其中在方案第二部分“实施数字化转型行动”，有多处提到“物联网”相关的名词。
在这里插入图片描述

那这波政策对我们做性能的技术人有什么影响，个人猜测有以下两点：

设备数字化改造，这个会带来大量的物联网测试机会，对从事该方向的从业人员是一个利好消息；
乘着这波大更新，剔除漂亮国留下的暗门，也就是信创改造，针对信创的适配和测试估计会有一波红利。

那么，今天我们主要聊聊“物联网”这块的压测，说道物联网那必然绕不开 MQTT，它甚至已经成为物联网系统事实上的网络协议标准。如果你想从事物联网系统压测，就一定要掌握 MQTT 消息中间件压测方法。

二、MQTT 压测常见场景

不同的协议有各自的特定需求，需要设计不同的场景和测试用例，但是在 MQTT 设计性能测试时，我们可以参考以下几种常见的通用压测场景：

BenchMark ：基准测试，即纯数通测试，不带业务规则，从而为后续实际业务压测场景做数据比对。
基准场景：单业务容量，即将每一个业务都压到最大TPS，从而为后续场景做数据比对。
容量场景：混合业务容量性能场景，即将所有业务根据比例加到一个场景中，在数据、软硬件环境、监控等的配合之下，分析瓶颈并调优的过程。
稳定性场景：核心就是时长。在长时间的容量场景运行之下，观察系统的性能表现，分析瓶颈并调优的过程。
异常场景：在长时间的容量场景运行之下，然后就是异常的定义最为重要。之前我们常用的手段就是岩主机、岩服务、岩网卡。随着云原生架构的发展，现在我们还有岩容器、岩虚机、岩缓存、岩队列等等。实际的场景中要模拟什么样的异常，一定是根据系统的MQTT消息中间件架构分析而来的。

三、MQTT常见业务场景

首先，我们大概了解下MQTT的基础概念。

MQTT（MQ Telemetry Transport）协议，是 IBM 公司在 1999 年开发的轻量级网络协议，它有三个主要特点：

采用二进制的消息内容编码格式，所以二进制数据、JSON 和图片等负载内容都可以方便传输。
协议头很紧凑，协议交互也简单，保证了网络传输流量很小。
支持 3 种 QoS（Quality of Service，服务质量）级别，便于应用根据不同的场景需求灵活选择。

这三个特点，让 MQTT 协议非常适合计算能力有限、网络带宽低、信号不稳定的远程设备，所以它成为了物联网系统事实上的网络协议标准。

MQTT 属于发布 - 订阅模式，其中包含三个角色，分别是发布者（Publisher）、经纪人（Broker）和订阅者（Subscriber），它们的关系如下图所示。

在这里插入图片描述
相关概念：

Publisher（发布者）：消息的发出者，负责生产数据。发布者发送某个主题的数据给经纪人，发布者不知道订阅者。
Subscriber（订阅者）：消息的订阅者，订阅经纪人管理的某个或者某几个主题。
Broker（经纪人）：当经纪人接收到某个主题的数据时，将数据发送给这个主题的所有订阅者。
Topic（主题）：可以理解为消息队列中的路由，订阅者订阅了主题之后，就可以收到发送到该主题的消息。
Payload（负载）；可以理解为发送消息的内容。
QoS（消息质量）：全称 Quality of Service，即消息的发送质量，主要有 QoS 0、QoS 1、QoS 2三个等级，下面分别介绍下：
- QoS 0（Almost Once）：至多一次，只发送一次，会发生消息丢失或重复；
- QoS 1（Atleast Once）：至少一次，确保消息到达，但消息重复可能会发生；
- QoS 2（Exactly Once）：只有一次，确保消息只到达一次。

在 发布/订阅模型 的背景下，设计 MQTT 测试场景的关键在于考虑如何模拟发布者和订阅者的不同行为，主要包括以下场景的场景：

连接：客户端在一定时间内连接到 Broker，并与 Broker 维持连接一段时间。
广播：大量客户端作为订阅者，只有少数或单个发布者。
点对点：发布者客户端和订阅者客户端数量相同。
上报：大量客户端作为发布者，只有少数或单个订阅者。

1、并发连接

MQTT 连接是一种基于 TCP 的长连接。客户端首先与 MQTT Broker 建立 TCP 连接，然后发送 MQTT 登录请求。连接成功建立后，客户端和 MQTT Broker 通过定期发送心跳包来维持连接状态。所以建立和长期维持一个MQTT连接是需要占用MQTT broker一定资源的，在高并发场景下，这种长连接会消耗 Broker 的大量资源。因此，通过压测，我们可以评估 MQTT Broker 在有限资源下能够承受多少并发连接。

并发连接场景我们主要关注以下两个指标：

并发连接数：
连接速率

并发连接数
维持海量设备连接需要消耗大量的计算资源，在并发连接测试中还要考虑是否使用 TLS/SSL 加密传输，因为它会增加压力机和MQTT Broker额外的资源开销。在计划测试时，需要评估它对性能的影响。

比如常见技术指标：支持千万级设备在线，背景连接 (只连接不发送消息)

连接速率
即每秒新增连接数越高，需要的计算资源越多，在制定测试场景时需要考虑这个因素，因为在有些场景下大量的设备会同时上线，在测试 broker 的能力或规划系统容量时需要这个指标。

比如，实际项目我们在模拟异常场景在连接故障的时候，实现了整个连接 FailOver，避免设备批量故障、云平台发布、网络抖动等原因导致大规模设备集体上线、下线，从而触发整个平台雪崩。

比如常见的技术指标：能支持百万设备掉线 3 分钟故障转移目标。支持百万长连接的 session 在分钟内迁移，可用于容灾、发布断连等场景。

综上所述，在 MQTT 并发连接测试中，应该考虑以下几种场景：

在固定的较低连接速率下逐步提高并发连接数，测试系统响应和资源消耗情况。这可以确定系统在给定的硬件和网络资源下能够承受的最大并发数。
在给定的并发连接数下，测试不同连接速率下系统的响应和资源消耗情况。
在给定的并发连接数下，测试海量连接并发瞬时连接，测试所有连接完成所需时间，期间平台不会雪崩。
在设计时，区分普通 TCP 连接和 TLS/SSL 加密连接。

2、消息吞吐量测试

如前文所述，MQTT 是一种基于发布/订阅模式的消息传输协议，它是一种异步协议，实现了发布-订阅 1对1，1对多，多对1这3种类型，广泛应用于各种物联网场景。因此，消息吞吐量测试应该涵盖以下三种场景：

2.1 1 对 1

发布者和订阅者的数量相等。对于每个发布者，有唯一一个订阅者订阅其发布的主题。也就是说，MQTT Broker 的消息流入速率与流出速率相同。
在这里插入图片描述
举例场景：

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

2.2 多对1（上报）

一种典型的物联网应用场景，有大量物联网设备作为发布者，但只有少数或单个订阅者，例如大量设备上报其状态或数据。
在这里插入图片描述
举例场景：

场景名称：千万连接+消息吞吐
描述：1000 万 MQTT TCP 并发连接，心跳间隔 200s。其中 700 万为背景连接 (只连接不发送消息)，300 万活跃用户，每个用户每隔 15S 上报一条 QOS 0 的消息，payload 为 100B。消息通过规则引擎桥接到 Kafka。稳定性运行30分钟。
期望结果：内网测试成功率为 100%，无消息积压，CPU 和内存在测试期间表现平稳，没有大幅度的抖动。

2.3 1对多

即广播模式，少量客户端发布消息，大量设备端订阅消费消息，如控制端指令下发。
在这里插入图片描述

举例场景：

场景名称：消息广播
描述：1000 万 MQTT TCP 并发连接，所有连接均订阅同一个 OTA 广播主题(QoS 0，payload 为 100B)。模拟一个 MQTT 客户端每隔 10 分钟向该主题广播一条消息，测试 30 分钟
期望结果：内网测试成功率为 100%，所有订阅客户端成功消费 3 条消息

另外，在设计消息吞吐量场景时，不要忽略 QoS、消息有效载荷大小、带通配符的订阅主题等因素。不同的 QoS 对负载测试的性能和资源消耗有很大影响。有效载荷大小可以根据实际使用情况确定。

2.4 其它场景

对于其它 MQTT 功能，如共享订阅、消息转存到数据库或其他消息队列（MQ）、海量主题订阅等极端情况，可以根据实际需求进行设计并加入测试场景中。

三、MQTT常见性能指标

指标一般可以分为两大类：应用指标（比如 MQTT Broker 的指标）和计算资源指标。

应用指标与用户场景和需求有关，例消息时延、并发连接数、数据吞吐量（TPS）等。
计算资源指标与硬件资源消耗有关，例如 CPU、内存、网络、磁盘 I/O。

常见的指标如下表所示：
在这里插入图片描述

四、MQTT常见性能工具

1、emqtt-bench

emqtt-bench 是 emqx 编写的用于测试 MQTT 服务器性能 BenchMark 的测试程序，使用 Erlang 语言编写，与其它工具（如：JMeter）相比，emqtt_bench 的优点是安装和使用简单，占用的计算资源较少。但它支持的场景比较有限，需要结合其他监控工具测试指标数据。

在这里插入图片描述