大件分拣性能测试实践分享-京东云开发者社区

### 1 性能测试基础知识

#### 1.1 名词概念

##### 1.1.1 响应时间

1. 定义：从用户发送一个请求到用户接收到服务器返回结果的时间。
2. 响应时间与系统负载的关系：
- 响应时间随着系统负载逐步增加；
- 在拐点处意味着系统的一种或多种资源利用达到的极限；
- 通常可以利用拐点来进行性能测试分析与定位；

##### 1.1.2 吞吐量

1. 定义：单位时间内系统处理的用户请求数量；
2. 计算单位：一般使用请求数/秒做为吞吐量的单位，也可以使用页面数/秒来表示； 另外，从业务角度来说也可以使用访问人数/天或页面访问量/天做为单位，在性能测试中，常使用请求数/秒作为单位；
3. 吞吐量与系统负载对应关系：
- 吞吐量逐随着用户请求数的增加而增加并逐渐达到饱和；
- 在系统的拐点开始意味着系统的一种或多种资源利用达到的极限；
- 通常可以利用拐点来进行性能测试分析与定位 ；

##### 1.1.3 并发数

- 并发用户数：某一物理时刻同时向系统提交请求的用户数，提交的请求可能是同一个场景或功能，也可以是不同场景或功能；
- 在线用户数：某段时间内访问系统的用户数，这些用户并不一定同时向系统提交请求；
- 系统用户数：系统注册的总的用户数；

三者之间的关系：系统用户数 >= 在线用户数 >= 并发用户数；

##### 1.1.4 资源利用率

1. 定义：指的是对不同系统资源的使用程度，通常以占用最大值的百分比来衡量；
2. 常用指标如下：
- CPU：就像人的大脑，主要负责相关事情的判断以及实际处理的机制；
- 内存：大脑中的记忆块区，将眼睛，皮肤等收集到的信息记录起来的地方，以供cpu进行判断，但是是临时的，访问速度快，如果关机或断电这里的数据会消失；
- 磁盘IO：大脑中的记忆区块，将重要的数据保存起来（永久保存，关机或断电不会丢失，速度慢），以便将来再次使用这些数据；

##### 1.1.5 其它常用概念

1. TPS：Transactions Per Second，每秒系统处理的事务数；
2. 思考时间：用户每个操作后的暂停时间，或者叫操作之间的间隔时间，此时间内是不对服务器产生压力的；
3. 点击数：每秒钟用户向WEB服务器提交的HTTP请求数。这个指标是WEB应用特有的一个指标：WEB应用是"请求-响应"模式，用户发出一次申请，服务器就要处理一次，所以点击是WEB应用能够处理的交易的最小单位。如果把每次点击定义为一个交易，点击率和TPS就是一个概念。容易看出，点击率越大，对服务器的压力越大。点击率只是一个性能参考指标，重要的是分析点击时产生的影响。需要注意的是，这里的点击并非指鼠标的一次单击操作，因为在一次单击操作中，客户端可能向服务器发出多个HTTP请求。

#### 1.2 性能测试类型

- 基准测试：在给系统施加较低压力时，查看系统的运行状况并记录相关数做为基础参考；
- 负载测试：是指对系统不断地增加压力或增加一定压力下的持续时间，直到系统的某项或多项性能指标达到安全临界值，例如某种资源已经达到饱和状态等；
- 压力测试：压力测试是评估系统处于或超过预期负载时系统的运行情况，关注点在于系统在峰值负载或超出最大载荷情况下的处理能力；
- 稳定性测试：在给系统加载一定业务压力的情况下，使系统运行一段时间，以此检测系统是否稳定；
- 并发测试：测试多个用户同时访问同一个应用、同一个模块或者数据记录时是否存在死锁或者其他性能问题，同时关注系统的指标是否已饱和或超饱和；

### 2 性能测试流程

- 测试点分析
- 测试准备
- 测试执行
- 结果分析与调优
- 报告生成与评审

#### 2.1 测试点分析

##### 2.1.1 确定性能测试点

在实施性能测试之前，我们需要对被测系统做相应的评估，主要目的是明确是否需要做性能测试。如果确定需要做性能测试，需要进一步确立性能测试点和指标，明确该测什么、性能指标是多少，测试通过、不通过的标准，性能指标也会根据情况评估，要求被测系统能满足将来一定时间段的业务压力。判断是否进行性能测试主要从下面两个方面进行：

1. **核心业务且日请求量较高：**
首先从系统层面，需要判断该系统支撑的业务是不是业务条线里的核心业务，根据部门对系统的评级，可以确定为测试点；其次是功能点层面，需要判断该功能点是否是系统的核心功能或主要流程，以此来确定测试点。测试的系统及功能点确认后，需要收集功能点日常的请求量及峰值（可以统计不同时间粒度下的请求量，如：小时，日，周，月）。如果日请求量很高，系统压力很大，而且又是关键业务，该项目需要做性能测试，而且关键业务点，可以被确定为性能点。
2. **逻辑复杂度高：**
如果一个主要业务的日请求量不高，但是逻辑很复杂，同时该功能还被其他的业务使用。这种情况下为了防止该业务性能下降而影响到其他业务，通常情况下，该业务也需要进行性能测试。
3. **新功能：**
如果功能点是近期新加的功能点，且上线后预计请求量很高，则可以在上线前先做性能测试，确保上线后对系统的性能有一个评估。
除了根据以上几点来进行判断以外，还要结合实际情况来进行确定，比如我们的系统每年618或者双十一都会做性能测试，若是时间有限，或者核心业务无代码改动，这样可能部分核心业务，日请求量高的功能点就不会被确定为性能测试点。

##### 2.1.2 确定性能测试目标

压测的性能测试目标值可以由以往该功能点每分钟的最大请求量来作为基准，乘以一个请求放大倍数，比如大促时按上次的单量乘以一个放大系数作为本次的测试目标。

#### 2.2 性能测试准备

##### 2.2.1 压测计划制定

压测计划的制定是由研发人员、测试人员共同制定，根据测试点以及测试目标制定压测计划。

- 压测周期
- 压测环境搭建
- 压测人员
- 压测报告生成
- 压测结果评审
- 调优
- 复测

##### 2.2.2测试环境准备

- 系统运行环境：压测环境最好单独搭建一套且配置与生产环境保持一致，如果是用测试环境或线上环境，可能存在性能测试把环境压垮从而影响其它功能的正常使用，所以，通常需要重新搭建一套专门用来做性能测试的环境；
- 执行机环境：这个就是用来生成负载的执行机，通常需要在物理机上运行，目前主要使用京东压测平台；

#### 2.2.3 测试方案设计和评审

根据性能需求分析来设计符合用户使用习惯的场景，场景设计的好坏直接影响到性能测试的效果；

##### 2.2.4 性能工具准备

- 负载工具：根据需求分析和系统特点选择合适的负载工具，比如forcebot等；
- 监控工具：准备性能测试时的服务器资源、JVM、数据库监控工具，以便进行后续的性能测试分析与调优；

##### 2.2.5 测试脚本准备

如果性能测试工具不能满足被测系统的要求或只能满足部分要求时，需要我们自己开发脚本配合工具进行性能测试；

##### 2.2.6 测试数据准备

- 负载测试数据：并发测试时需要多少数据并发量，多少业务数据等，尽可能模拟生产环境；
- DB数据量大小：为了尽量符合生产场景，需要模拟线上大量数据情况，那么要往数据库里提前插入一定的数据量。这可能需要花费一些时间，特点是关联系统较多，逻辑复杂的业务可能同时涉及多张表；

##### 2.2.7 其它

如果需要其它其它关联系统或专业人士如DBA配合的，也需要提前进行沟通；

#### 2.3 测试执行

在完成上述的数据及环境准备后，接下来进入到用例执行阶段。

##### 2.3.1 执行注意事项

1. 用例执行先按一个请求进行试跑，验证环境的可用性，监控工具、分析工具是否正常可用；
2. 确认一切正常后，再逐步增加请求数，直到TPS满足目标值；
3. 测试执行过程中，要准备充足的压测数据，注意压测时长不宜过长，也不宜过短，压测前设置执行时间；
4. 压测过程中注意观察各项指标，比如应用的CPU、负载、网络IO以及数据库CPU、TPS、活跃连接数等指标。如果有使用Redis、ES等中间件也需要观察集群及节点的各类指标，注意瓶颈点；
5. 混合场景压测时，要注意每个性能测试点的并发用户数的选取，不宜过大或过小；

##### 2.3.2 测试执行过程

1. 基准测试：同一性能测试点，多次执行，查看系统的运行状况并记录相关数做为基础参考；
2. 负载测试：同一性能测试点，不断地增加压力或增加一定压力下的持续时间，直到系统的某项或多项性能指标达到安全临界值，例如某种资源已经达到饱和状态；
3. 稳定性测试：同一性能测试点，挑选符合要求的并发数，使系统运行一段时间，以此检测系统是否稳定；
4. 混合场景测试：各性能测试点，挑选符合各自要求的最优并发数，使其一起运行，检测系统的各项指标情况；注意混合场景测试时，各性能测试点的并发数要选取的合理，不宜过大；
5. 调优或扩容后复测：对于性能测试点，若是测试过程中，还未达到期望目标时，系统的某项指标已达到临界值，此时需要研发同学进行优化或者处理后，再重新测试。

#### 2.4 结果分析与调优

1. 当压测过程中TPS比目标值小，且小很多，此时我们可以采取一次多加几个并发，然后再进行观察；
2. 当压测过程中TPS大于目标值，且没有高出太多时，应用CPU、数据库压力、TP99等各项指标都满足要求，此时就是我们的压测最优结果；
3. 当继续增加并发数进行压测，当数据库压力超过目标值，或者应用CPU超过目标值，或者随着请求数量的增多，响应时间逐渐变长，此时就达到了性能拐点；
4. 当压测过程中TPS还未达到目标值时，已经遇到了性能拐点，那此次压测结果就不满足要求，需要进行分析并给予建议。

#### 2.5 报告生成与评审

完成了所有压测任务以后，最后生成总结性的性能测试报告，并进行评审。评审通过后，压测结束。

### 3 大件分拣性能测试实践

#### 3.1 大件分拣系统测试点分析

##### 3.1.1 测试点分析

首先本部门整体负责压测工作的同学收集并整理好各系统的黄金链路节点，然后组会分析哪些功能点需要进行性能测试，考虑到今年618到双十一期间分拣系统的修改点和修改量，还有给予测试同学压测的时间等等因素，确定了大件分拣系统测试点包含8个功能点。

##### 3.1.2 压测目标

研发同学整理好系统各功能点在2020年618和双十一期间，0点大促时峰值的各项数据（TPS、TPP、服务器个数等），2021年压测的目标以这两次峰值的较大者的#倍作为压测目标：

#### 3.2 大件分拣性能测试准备

##### 3.2.1 测试环境准备

1）系统运行环境：搭建压测环境，并整理好相应的环境信息

![](//img1.jcloudcs.com/developer.jdcloud.com/de2323f5-3c41-455e-a9ac-29fd5bac5a3820220228162640.png)

2）监控数据准备：

![](//img1.jcloudcs.com/developer.jdcloud.com/a236957d-8fbd-4a5f-af82-fb19258b398220220228162657.png)

3）执行机环境：京东物流用的压测环境，执行机就用这个平台的机器。

##### 3.2.2 测试方案设计和评审

将分拣系统和压测环境的信息进行对比以后，按照生产环境和测试环境的机器比例是6:1（生产环境12台，压测环境2台）换算以后得到的测试指标量，将压测环境的测试指标和测试方案和研发进行评审，若有异议的地方要达成一致。

场景设计包含单场景，负载测试和混合场景测试，注意场景执行时长不宜过短，如下图：

![](//img1.jcloudcs.com/developer.jdcloud.com/1f1a730d-4f45-461e-8fd8-63bd23278d9a20220228162724.png)

##### 3.2.3 性能工具准备

1. 负载工具： forcebot
2. 监控工具： 
- UMP监控
- 数据库监控
- 慢SQL查看
- 日志查询
- CPU监控

##### 3.2.4 测试脚本准备

1）创建脚本的平台： forcebot，在脚本管理里面-创建脚本页面，目前支持HTTP脚本，JSF脚本，自定义脚本等等，具体使用方法参考forcebot操作手册，若是使用此平台遇到问题在答疑群进行咨询forcebot答疑群

![](//img1.jcloudcs.com/developer.jdcloud.com/22bbb860-b589-4301-b5ae-f1f06753e28f20220228163307.png)

2）测试脚本在压测环境执行
执行脚本内容，确保压测环境可正常工作
脚本内容举例：

![](//img1.jcloudcs.com/developer.jdcloud.com/71720c3e-19ac-4cb2-a59c-399b3e55e35a20220228163338.png)

##### 3.2.5 测试数据准备

首先分析大件分拣的全流程业务，明白测试数据的准备从接单开始，接单造数我们可以用forcebot平台随机生成，也可以自己写代码手动生成；下图是生成单据的例子。

![](//img1.jcloudcs.com/developer.jdcloud.com/3d61472f-84c6-4c2c-a0e3-dae1560d997820220228163403.png)

#### 3.3 大件分拣性能测试执行

##### 3.3.1 单接口压测

由于压测的接口较多，单接口压测只选取其中一个接口举例分享，分拣系统通过测试数据准备，两步操作以后，这些数据就可以用来做#接口功能的性能测试。

1. 测试功能点： #接口1
2. 性能指标：TPS:##/s  TP99:##ms CPU：<##%
3. 并发数：1
4. 压测执行时间：
包裹数量：40，测试执行时间：2021-09-26 18:30-2021:18:35
包裹数量：20，测试执行时间：2021-09-26 20:40-2021:20:50
1. 监控数据，并记录结果

一次提交20个包裹

![](//img1.jcloudcs.com/developer.jdcloud.com/336a1a7c-d230-4bcf-ac5c-6a3f6ebf5d7120220228163457.png)

一次提交40个包裹：

![](//img1.jcloudcs.com/developer.jdcloud.com/40462d15-4ca8-4a03-b2b4-8ecfc67fdde820220228163520.png)

一次提交20个包裹

![](//img1.jcloudcs.com/developer.jdcloud.com/7e34678a-6746-4868-9e69-20d68e88aaf820220228163538.png)

一次提交40个包裹：

![](//img1.jcloudcs.com/developer.jdcloud.com/3b4a5773-7191-456a-8c43-d5da3051bdb120220228163556.png)

forcebot监控数据：

![](//img1.jcloudcs.com/developer.jdcloud.com/be4a8f28-607a-44ad-b4fa-a269eedafcf420220228163621.png)

##### 3.3.2 混合场景压测

1. 混合场景：#MQ1，#worker2，#接口3，#worker4，#worker5，
2. 性能指标：
![](//img1.jcloudcs.com/developer.jdcloud.com/a083efd8-7dc1-4066-ab99-62d404444e5f20220228163655.png)
1. 压测开始时间：2021-10-09 15:10
2. 监控数据：
UMP/MDC/火眼

worker2
![](//img1.jcloudcs.com/developer.jdcloud.com/62986b05-f3ac-4988-b089-6dcb7e40ee0720220228163838.png)

接口3：

![](//img1.jcloudcs.com/developer.jdcloud.com/f4c0a08c-151c-43f9-80be-c9ce78c8f3e920220228163902.png)

worker4:

![](//img1.jcloudcs.com/developer.jdcloud.com/713fb140-d4f8-4408-bb0d-9f4cb1a865af20220228163959.png)

worker5：

![](//img1.jcloudcs.com/developer.jdcloud.com/555a295c-6a01-45b8-8b32-e9d2e8dc9f5a20220228164023.png)

数据库CPU：

![](//img1.jcloudcs.com/developer.jdcloud.com/ee76952c-1182-4598-b6e0-6f641068b86a20220228164050.png)

应用CPU：

![](//img1.jcloudcs.com/developer.jdcloud.com/096874ef-5f53-48e2-9b00-584075350fc020220228164110.png)

#### 3.4 大件分拣性能测试结果分析与调优

##### 3.4.1 第一轮压测结论

测试结论：#接口1压测环境服务器压测，并发数1，包裹数：40，tps：## /s，tp99：##ms，service的CPU高达##%，不满足当前预期指标 。建议代码优化后复测。

##### 3.4.2 第二轮压测结论

测试结论：#接口压测环境单台服务器压测，并发数1，包裹数：40，tps：##/s，tp99：##ms，service的CPU高达##%，不满足当前预期指标，建议扩容。
测试结论：混合场景：#MQ1，#worker2，#接口3，#worker4，#worker5，此混合场景下service应用的CPU高达##%，建议扩容。数据库CPU高达##%，建议升级数据库配置。

#### 3.5 大件分拣性能测试报告生成与评审

##### 3.5.1 压测结果总结

包裹验收接口第一轮测试满足目标值时，应用CPU达到##%，代码优化后第二轮复测，满足目标值时，应用CPU达到##%，建议扩容应用机器。

混合场景包含的功能：#MQ1，#worker2，#接口3，#worker4，#worker5，此场景应用CPU高达##，DB CPU高达##%，建议扩容应用的机器，升级数据库配置。

##### 3.5.2 压测范围

本次大件分拣共压测6个接口，2个worker，2个混合场景，总共10个压测场景

##### 3.5.3 压测目标

黄金流程参考20年双十一的峰值和21年618的峰值，二者取最大值，按照最大值的#倍进行压测

##### 3.5.4 压测报告解读

分拣本次压测覆盖八个单业务场景，与两个混合场景，第一轮压测CPU过高，经过代码优化后复测，CPU仍超过##%，不满足当前预期指标，需要扩容；两个混合场景中均发现应用或数据库CPU过高的情况，应用与数据库均需要扩容

------------

###### 自猿其说Tech-京东物流技术发展部
###### 作者：陈小兰