文章目录一、政策解读二、MQTT 压测常见场景三、MQTT常见业务场景1、并发连接2、消息吞吐量测试2.1 1 对 12.2 多对1上报2.3 1对多2.4 其它场景三、MQTT常见性能指标四、MQTT常见性能工具1、emqtt-bench2、JMeter五、小结一、政策解读微信公众号“工信微报”4月9日消息工业和信息化部、国家发展改革委、财政部、中国人民银行、税务总局、市场监管总局、金融监管总局等七部门近日联合印发《推动工业领域设备更新实施方案》提出到 2027 年工业领域设备投资规模较 2023 年增长 25 %以上规模以上工业企业数字化研发设计工具普及率、关键工序数控化率分别超过 90 %、75 %工业大省大市和重点园区规上工业企业数字化改造全覆盖重点行业能效基准水平以下产能基本退出、主要用能设备能效基本达到节能水平本质安全水平明显提升创新产品加快推广应用先进产能比重持续提高。其中在方案第二部分“实施数字化转型行动”有多处提到“物联网”相关的名词。那这波政策对我们做性能的技术人有什么影响个人猜测有以下两点设备数字化改造这个会带来大量的物联网测试机会对从事该方向的从业人员是一个利好消息乘着这波大更新剔除漂亮国留下的暗门也就是信创改造针对信创的适配和测试估计会有一波红利。那么今天我们主要聊聊“物联网”这块的压测说道物联网那必然绕不开 MQTT它甚至已经成为物联网系统事实上的网络协议标准。如果你想从事物联网系统压测就一定要掌握 MQTT 消息中间件压测方法。二、MQTT 压测常见场景不同的协议有各自的特定需求需要设计不同的场景和测试用例但是在 MQTT 设计性能测试时我们可以参考以下几种常见的通用压测场景BenchMark 基准测试即纯数通测试不带业务规则从而为后续实际业务压测场景做数据比对。基准场景单业务容量即将每一个业务都压到最大TPS从而为后续场景做数据比对。容量场景混合业务容量性能场景即将所有业务根据比例加到一个场景中在数据、软硬件环境、监控等的配合之下分析瓶颈并调优的过程。稳定性场景核心就是时长。在长时间的容量场景运行之下观察系统的性能表现分析瓶颈并调优的过程。异常场景在长时间的容量场景运行之下然后就是异常的定义最为重要。之前我们常用的手段就是岩主机、岩服务、岩网卡。随着云原生架构的发展现在我们还有岩容器、岩虚机、岩缓存、岩队列等等。实际的场景中要模拟什么样的异常一定是根据系统的MQTT消息中间件架构分析而来的。三、MQTT常见业务场景首先我们大概了解下MQTT的基础概念。MQTTMQ Telemetry Transport协议是 IBM 公司在 1999 年开发的轻量级网络协议它有三个主要特点采用二进制的消息内容编码格式所以二进制数据、JSON 和图片等负载内容都可以方便传输。协议头很紧凑协议交互也简单保证了网络传输流量很小。支持 3 种 QoSQuality of Service服务质量级别便于应用根据不同的场景需求灵活选择。这三个特点让 MQTT 协议非常适合计算能力有限、网络带宽低、信号不稳定的远程设备所以它成为了物联网系统事实上的网络协议标准。MQTT 属于发布 - 订阅模式其中包含三个角色分别是发布者Publisher、经纪人Broker和订阅者Subscriber它们的关系如下图所示。相关概念Publisher发布者消息的发出者负责生产数据。发布者发送某个主题的数据给经纪人发布者不知道订阅者。Subscriber订阅者消息的订阅者订阅经纪人管理的某个或者某几个主题。Broker经纪人当经纪人接收到某个主题的数据时将数据发送给这个主题的所有订阅者。Topic主题可以理解为消息队列中的路由订阅者订阅了主题之后就可以收到发送到该主题的消息。Payload负载可以理解为发送消息的内容。QoS消息质量全称 Quality of Service即消息的发送质量主要有 QoS 0、QoS 1、QoS 2三个等级下面分别介绍下QoS 0Almost Once至多一次只发送一次会发生消息丢失或重复QoS 1Atleast Once至少一次确保消息到达但消息重复可能会发生QoS 2Exactly 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对11对多多对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 0payload 为 100B)。模拟一个 MQTT 客户端每隔 10 分钟向该主题广 播一条消息测试 30 分钟期望结果内网测试成功率为 100%所有订阅客户端成功消费 3 条消息另外在设计消息吞吐量场景时不要忽略 QoS、消息有效载荷大小、带通配符的订阅主题等因素。不同的 QoS 对负载测试的性能和资源消耗有很大影响。有效载荷大小可以根据实际使用情况确定。2.4 其它场景对于其它 MQTT 功能如共享订阅、消息转存到数据库或其他消息队列MQ、海量主题订阅等极端情况可以根据实际需求进行设计并加入测试场景中。三、MQTT常见性能指标指标一般可以分为两大类应用指标比如 MQTT Broker 的指标和计算资源指标。应用指标与用户场景和需求有关例消息时延、并发连接数、数据吞吐量TPS等。计算资源指标与硬件资源消耗有关例如 CPU、内存、网络、磁盘 I/O。常见的指标如下表所示四、MQTT常见性能工具1、emqtt-benchemqtt-bench 是 emqx 编写的用于测试 MQTT 服务器性能 BenchMark 的测试程序使用 Erlang 语言编写与其它工具如JMeter相比emqtt_bench 的优点是安装和使用简单占用的计算资源较少。但它支持的场景比较有限需要结合其他监控工具测试指标数据。具体安装和使用方法请参考 性能工具之emqtt_bench快速上手2、JMeter如果要进行大规模业务压测我们推荐另一款更专业的性能和负载测试工具 - JMeter。JMeter 提供了基于 MQTT 协议开源测试插件https://github.com/xmeter-net/mqtt-jmeter 。目前 JMeter MQTT 插件的最新版本为 2.0.2支持连接、消息发布、消息订阅等多种采样器并可通过组合构建更复杂的测试场景。五、小结物联网系统在架构、网络模式、通信协议等方面与传统的互联网系统有所区别。因此传统的性能测试方法不能直接套用到物联网系统中。首先物联网系统压测的对象主要是“设备”而非“用户”需要模拟大量设备进行连接和通信并产生海量的数据。所以模拟真实的设备规模非常重要这需要对生成压测工具进行更精细的设计以及对测试结果进行更有效的分析。其次物联网的通信方式与互联网不同因此多种物联网通信协议应运而生。对于 MQTT 协议它所具备的一些特点使其与互联网消息协议有很大的区别MQTT 是轻量级的专为不稳定的网络连接和节省带宽而设计。MQTT 使用 QoS 来支持复杂的设备网络环境。MQTT 与数据无关。MQTT 是一种基于 TCP 的长连接具有持久会话的特性。因此在对 MQTT 协议压测进行测试时要注意考虑它的独特性。参考资料构建可靠的物联网系统了解 MQTT 性能测试MQTT 性能测试入门常见测试场景和指标阿里云物联网平台技术解读与实践物联网平台业务链路设计方案EMQ X 企业版 4.3.0 千万并发连接、千万订阅和百万消息吞吐性能测试报告.pdf下一代车联网设计与实现.pdf