项目背景：机器人调度平台
迭代背景：敏捷开发
记录方向：mqtt压测
记录时间：20211009
===================================================
生产环境上线后，前期主要关注的是功能正确，非功能性的测试内容没有过多关注，生产环境上线一段时候后，领导要求进行相关的性能测试。这里记录一下编写测试计划及重点测试问题（主要是rabbitmq方面）的处理处理过程；
=====================================性能测试计划=====================================
性能测试计划——10万+设备并发
一、前言... 1
二、准备工作... 1
2.1、系统基本功能验证... 1
2.2、测试团队组建... 1
2.3、工具选择... 2
2.4、预先业务场景分析... 2
三、测试计划... 2
3.1、性能测试项目相关信息... 2
3.2、测试环境准备... 3
3.2.1、UAT和PRO对比... 3
3.3、性能场景分析及业务建模... 3
3.4、确定性能指标... 3
3.5、测试脚本开发... 4
四、测试实施... 4
4.1、测试环境确认... 4
4.2、执行测试脚本... 4
4.3、记录测试结果... 4
4.4、阶段进度统计... 4
五、测试分析... 4
5.1、测试环境的系统性能分析... 4
5.2、硬件设备对系统性能表现的影响因素... 4
5.3、其他影响因素分析... 4
5.4、测试中发现的问题... 4
5.5、测试后续跟踪... 4
一、前言
现在MARS系统基本的功能已经稳定，且后端框架基本定型，是时候来一个全身体检了。领导提出MARS系统必须支持10万+的设备并发的模糊需求，没有明确的各种系统资源水位，响应时间等具体指标，也没有明确前段的用户并发。现在根据该模糊需求制定一个比较笼统大概的性能测试计划，只针对本次的性能测试需求，系统支持10万+的并发；
二、准备工作
2.1、系统基本功能验证
现在MARS系统已上生产环境，已经开始接入设备，设备信息上报、告警、设备控制已经打通，功能验证已经通过，整个服务端框架已经定型，可以进行性能测试中容量测试、配置测试。
2.2、测试团队组建
整个性能测试活动中的人员组成，需要各组成成员。在本次性能测试项目中项目负责人与产品为同一人，运维和DBA为同一人。
2.3、工具选择
常规的性能测试工具主要有jmeter、loadrunner等，根据本次的性能需求主要是通过mqtt发布订阅操作来进行模拟设备上进行发布、订阅消息。经过调研，jmeter有相关mqtt协议的开源插件，但是插件效果不是很适用且有bug，所以直接采用python+第三方mqtt库来模拟完成设备的发布订阅操作。
2.4、预先业务场景分析
本次的性能需求为支持10万+的设备并发，根据I型机器人与平台的通讯协议（I型机器人的通讯协议比较全，就暂时按照I型的协议进行罗列），主要有以下几个方面的发布、订阅协议：设备登录认证、属性上报、组织下发协议、地图交互协议、作业交互协议、告警协议、初始化定位等协议。
截止目前接入****系统的机器人主要有以下几款协议：*****。
下表为不同机器人类型功能交互场景列举截图，具体的交互协议如下附件，****系统与机器人的交互协议主要为mqtt通讯，有少量的https接口。现在
三、测试计划
3.1、性能测试项目相关信息
|
序号 |
信息类型 |
说明 |
|
1 |
项目名称 |
***** |
|
2 |
项目类型 |
新建 |
|
3 |
项目背景 |
整体功能已经稳定，后端端架基本定型，已上生产环境 |
|
4 |
测试目的 |
容量测试、配置测试、负载测试、压力测试、性能验证 |
|
5 |
测试范围 |
mqtt broker、各服务在10万+并发下业务处理能力 |
|
6 |
里程碑 |
测试计划、环境准备、测试实施、性能优化 |
|
7 |
影响因素 |
测试环境确定为UAt环境，测试环境与生产环境的配置不一致，无法准确评估生产环境的水位容量、没有具体的性能指标，指标是否通过无法明确界定 |
3.2、测试环境准备
现目前MARS系统的环境有：DEV、SIT、UAT、PRO四个环境，生产环境已经上线开始运行，已经有部分设备接入到生产环境中，不能直接用来作为性能测试的环境，有业务因素，也有技术不支持的因素。生产环境的压测是需要进行进行请求流量区分、影子库区分。所以确定使用最接近生产环境的UAT环境来进行性能测试。
3.2.1、UAT和PRO对比
现在UAT环境的各个服务的副本都是没有进行资源限定的如CPU、内存、带宽、磁盘大小、缓存等，也无法知晓生产环境的各服务的资源配置，无法对UAT和PRO环境的资源配置及服务部署形成有效的对比。找运维确认过，PRO环境的系统资源配置是比UAT环境的配置要高，且PRO环境各个服务所开的副本数量是比UAT环境的副本要多。所以暂时就不在这儿逻辑性能测试环境与PRO环境的具体差异，直接简单粗暴的使用UAT环境进行测试。
3.3、性能场景分析及业务建模
本次性能测试场景为10万+设备并发，根据此场景罗列出本次测试的核心业务场景。
根据上文的MARs系统的接入设备类型及设备占比进行统计得出每种接入的设备业务并发
|
10万+设备占比情况 |
||||
|
序号 |
设备类型 |
接入占比 |
并发数量 |
备注 |
|
1 |
***** |
10% |
10000 |
|
|
2 |
***** |
40% |
40000 |
|
|
3 |
***** |
35% |
35000 |
|
|
4 |
***** |
10% |
10000 |
|
|
5 |
***** |
5% |
5000 |
|
|
合计 |
100% |
100000 |
|
|
根据接入设备的实际占比情况及接入设备的通信协议开发测试脚本。
3.4、确定性能指标
3.5、测试脚本开发
四、测试实施
4.1、测试环境确认
性能测试确定为UAT环境，UAT环境配置如下。
4.2、执行测试脚本
4.3、记录测试结果
4.4、阶段进度统计
五、测试分析
5.1、测试环境的系统性能分析
5.2、硬件设备对系统性能表现的影响因素
5.3、其他影响因素分析
5.4、测试中发现的问题
5.5、测试后续跟踪
==========================性能测试过程中重点问题分析====================================
主要记录一下rabbitmq方面的问题，消息重复消费问题暂未发现，在前期编码的时候进行过重复消费异常做过相应处理；
1、rabbitmq集群在压测时所有的压力都堆积到一个node节点中；
分析：后续经过分析，运维人员配置rabbitmq的配置出现问题，重新修改配置后各个节点负载均衡；
2、通过模拟大量设备并发推送消息时有丢包现象；
分析：
原因1、mqtt broker接收到机器人推送的消息后发布到MQ发布失败，MQ内存超过限制，导致触发报警，报警解除前不允许新的发布
措施：增加MQ内存
原因2、消息者消费消息过慢，MQ宏消息堆积过多，导致消息堆积阻塞。消息堆积阻塞的本质就是生产消息速率大于消费消息速率，导致生产的消息大量堆积在队列中
措施：增加消费者数、提高消费者并发从而提高消费速率、提高消费者的预取文件数。