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

简介: 【4月更文挑战第18天】物联网系统在架构、网络模式、通信协议等方面与传统的互联网系统有所区别。因此,传统的性能测试方法不能直接套用到物联网系统中。

一、政策解读

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

image.png

其中在方案第二部分“实施数字化转型行动”,有多处提到“物联网”相关的名词。
image.png

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

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

那么,今天我们主要聊聊“物联网”这块的压测,说道物联网那必然绕不开 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),它们的关系如下图所示。

image.png

相关概念:

  • 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 的消息流入速率与流出速率相同。

image.png

举例场景:

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

2.2 多对1(上报)

一种典型的物联网应用场景,有大量物联网设备作为发布者,但只有少数或单个订阅者,例如大量设备上报其状态或数据。

image.png

举例场景:

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

    2.3 1对多

即广播模式,少量客户端发布消息,大量设备端订阅消费消息,如控制端指令下发。

image.png

举例场景:

  • 场景名称:消息广播
  • 描述: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常见性能工具

image.png

1、emqtt-bench

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

image.png

具体安装和使用方法请参考: 性能工具之emqtt_bench快速上手

2、JMeter

如果要进行大规模业务压测,我们推荐另一款更专业的性能和负载测试工具 - JMeter。

JMeter 提供了基于 MQTT 协议开源测试插件:https://github.com/xmeter-net/mqtt-jmeter

目前 JMeter MQTT 插件的最新版本为 2.0.2,支持连接、消息发布、消息订阅等多种采样器,并可通过组合构建更复杂的测试场景。

image.png

五、小结

物联网系统在架构、网络模式、通信协议等方面与传统的互联网系统有所区别。因此,传统的性能测试方法不能直接套用到物联网系统中。

首先,物联网系统压测的对象主要是“设备”,而非“用户”,需要模拟大量设备进行连接和通信,并产生海量的数据。所以模拟真实的设备规模非常重要,这需要对生成压测工具进行更精细的设计,以及对测试结果进行更有效的分析。

其次,物联网的通信方式与互联网不同,因此多种物联网通信协议应运而生。

对于 MQTT 协议,它所具备的一些特点使其与互联网消息协议有很大的区别:

  • MQTT 是轻量级的,专为不稳定的网络连接和节省带宽而设计。
  • MQTT 使用 QoS 来支持复杂的设备网络环境。
  • MQTT 与数据无关。
  • MQTT 是一种基于 TCP 的长连接,具有持久会话的特性。

因此在对 MQTT 协议压测进行测试时,要注意考虑它的独特性。

参考资料:

相关实践学习
钉钉群中如何接收IoT温控器数据告警通知
本实验主要介绍如何将温控器设备以MQTT协议接入IoT物联网平台,通过云产品流转到函数计算FC,调用钉钉群机器人API,实时推送温湿度消息到钉钉群。
阿里云AIoT物联网开发实战
本课程将由物联网专家带你熟悉阿里云AIoT物联网领域全套云产品,7天轻松搭建基于Arduino的端到端物联网场景应用。 开始学习前,请先开通下方两个云产品,让学习更流畅: IoT物联网平台:https://iot.console.aliyun.com/ LinkWAN物联网络管理平台:https://linkwan.console.aliyun.com/service-open
目录
相关文章
|
11天前
|
存储 机器学习/深度学习 算法
Python 物联网入门指南(七)(4)
Python 物联网入门指南(七)
17 1
|
11天前
|
存储 监控 Cloud Native
如何通过持续测试和调整来提高OLAP系统的性能和可扩展性?
【5月更文挑战第14天】如何通过持续测试和调整来提高OLAP系统的性能和可扩展性?
17 2
|
11天前
|
传感器 存储 物联网
Python 物联网入门指南(七)(1)
Python 物联网入门指南(七)
18 1
|
11天前
|
安全 搜索推荐 物联网
构建未来:基于Android的智能物联网家居系统
【5月更文挑战第15天】 在快速发展的数字化时代,智能物联网(IoT)技术与移动操作系统的结合正在塑造未来家居的生活方式。特别是Android平台,以其开放性、灵活性和广泛的用户基础,成为智能家居创新的理想选择。本文将探讨如何利用Android系统构建一个高效、安全且易于扩展的智能家居控制系统,涵盖系统设计、关键技术实现以及可能面临的挑战。通过分析具体案例,我们旨在为开发者和企业提供一套可行的解决方案蓝图,以促进智能家居领域的进一步发展。
|
11天前
|
存储 供应链 数据管理
Spartacus 在 Back-Office 修改库存后,下单测试,系统表现完美
Spartacus 在 Back-Office 修改库存后,下单测试,系统表现完美
19 2
|
11天前
|
前端开发 测试技术 数据安全/隐私保护
软件测试 —— 案例系统缺陷报告
软件测试 —— 案例系统缺陷报告
|
11天前
|
人工智能 安全 物联网
Python 物联网入门指南(八)(3)
Python 物联网入门指南(八)
16 1
|
11天前
|
存储 安全 机器人
Python 物联网入门指南(八)(2)
Python 物联网入门指南(八)
16 2
|
11天前
|
机器人 物联网 Python
Python 物联网入门指南(八)(1)
Python 物联网入门指南(八)
18 1
|
11天前
|
传感器 物联网 机器人
Python 物联网入门指南(七)(3)
Python 物联网入门指南(七)
10 1

相关产品

  • 物联网平台