前置说明
该章节只要记录真实测试过程。
1.简介
1.1 测试目标
本次测试的目的在于探查 __系统名称__ 版本的系统业务处理性能，以及在高负载情况下的系统表现。通过测试找出系统的性能瓶颈和分析可能的风险，为系统调优提供依据。
1.2 测试范围
1) 基准测试
无负载情况下，对所有功能点分别进行一段时间的持续运行，取得各功能点平均响应时间和TPS作为分析衡量指标，在每次发布时与上一版本发布时的基准测试结果进行对比，从而得出当前版本系统属于优化还是恶化性能。
2) 负载测试
根据业务性能需求，模拟一定时间之内设计并发用户同时向系统发出请求，检测出系统的响应能力，包括响应时间、CPU、内存等的使用情况，以验证系统对并发请求时的支持能力，并获取该系统的最大并发请求数量。
在该过程中通过性能拐点、TPS波动、CPU负载、内存负载等找出系统可能存在的性能问题，为调优提供数据。
3) 稳定性测试
通过长时间（4、6、8、12、24、24*7h等）高负载（系统最大处理能力的70%或80%或混合场景中某个压力值）运行模拟被测试系统的测试负载，观察系统是否潜在问题。
通过高负载和低负载的转换，以验证系统的正常情况下以及峰值情况下系统的稳定性。
4) 破坏性测试
对系统不断加压，直至系统崩溃，快速造成系统的崩溃或让问题明显的暴露出来；测试出系统的最大承受能力。确保系统失败并能正常恢复。
2.测试环境
2.1 软硬件环境
服务器资源表
| 设备 | 配置 | 软件配置 | 服务器IP地址 |
|---|---|---|---|
| 服务器A | Centos7（8核CPU、内存16G） | Java程序A | 192.168.1.111 |
| 服务器B | Centos7（8核CPU、内存16G） | Java程序B | 192.168.1.112 |
测试机资源表
| 设备 | 配置 |
|---|---|
| 主测试机A | Windows 11 家庭中文版（i7-1165G7、8核CPU、内存16G） |
| 分布式测试机B | Windows 11 家庭中文版（i7-1165G7、8核CPU、内存16G） |
| 分布式测试机C | Windows 11 家庭中文版（i7-1165G7、8核CPU、内存16G） |
2.2 测试工具
| 工具 | 版本 | 功能说明 |
|---|---|---|
| Jmeter | 5.5 | 提供并发请求能力 |
| Jmeter监控插件 | - | 提供服务器监控能力、请求监控能力 |
| jprofiler | - | 监控服务器CPU、 内存等情况 |
| arthas | 3.6.4 | 查看应用 load、内存、gc、线程的状态信息 |
| jemalloc | - | 分析堆外内存 |
| sysstat | - | 分析服务器线程、Cpu主动切换、被动切换情况 |
3.测试需求
3.1 性能测试需求
| 业务指标 | 指标描述 | 指标数 |
|---|---|---|
| 响应时间 | 用户操作时系统的响应时间 | |
| 并发数量 | 同时访问系统的最大并发用户数量- | |
| 访问高峰数量 | 同时访问系统的用户数量 | |
| 业务量均值 | 非实时批量数据量(笔) | |
| 业务量峰值 | 非实时批量数据量(笔) | |
| 访问高峰时间 | 访问系统频率最高的时间段 |
3.2 测试内容
| 序号 | 功能模块 | 功能描述 | 接口地址 |
|---|---|---|---|
| 1 | 功能A | http://192.168.1.110:9000/a | |
| 2 | 功能B | http://192.168.1.110:9000/b | |
| 3 | 功能C | http://192.168.1.110:9000/c |
3.3 测试风险
| 风险编号 | 风险描述 | 发生可能性(高/中/低) | 影响程度(高/中/低) | 规避方法 |
|---|---|---|---|---|
4.测试约束
4.1 测试启动条件
- 测试环境已经准备好；
- 系统的功能测试已经完成，并且功能测试报告通过了内部评审；
- 进行了冒烟测试，系统的性能测试是可测的；
- 不存在影响系统流程的缺陷；
4.２测试结束条件
- 根据性能测试计划执行所有测试用例，测试出系统基本性能参数，并分析系统性能瓶颈，系统调优后，达到需求定义的性能指标；
- 完成性能分析工作，性能指标验证结束；
- 性能测试报告通过内部评审；
5.测试执行与分析
5.1 基准测试
5.1.1 测试方法
通过jmeter脚本逐步递增线程，分别对单个功能点和多个功能进行请求，待tps出现拐点且在较小范围波动内稳定运行后结束脚本运行，取tps和响应时间的平均值作为测试的基准值，以了解系统的整体性能状况。
当系统存在性能问题时，可选择在“cpu高负载”、“内存高负载”、“TPS波动大”、“tpc周期波动”、“暴升高暴跌”等异常情况下停止基准测试，查找问题。
5.1.2 测试场景
5.1.2.1 单一功能
配置: 线程500，启动时间500s，永久循环，测试功能 “__接口名称__” TPS、响应时间的基准值。
.png)
.png)
.png)
.png)
.png)
.png)
.png)
测试结果描述和分析:
● TPS：__依据情况填写__
● 响应时间：__依据情况填写__
● 错误率: __依据情况填写__
● CPU负载、内存负载、磁盘负载：__依据情况填写__
5.1.2.1 混合功能
配置: 线程500，启动时间500s，永久循环，测试多个功能相同权重下请求的TPS、响应时间的基准值。
.png)
.png)
.png)
.png)
.png)
.png)
.png)
测试结果描述和分析:
● TPS：__依据情况填写__
● 响应时间：__依据情况填写__
● 错误率: __依据情况填写__
● CPU负载、内存负载、磁盘负载：__依据情况填写__
5.2 负载测试
5.2.1 测试方法
负载测试应该指定实际场景，如“200 个并发用户访问时的最大响应时间，最大吞吐量”、“21 个小时内要处理 1000 笔业务，找到最大并发数”、“响应时间不超过 10s 的最大负载”、“cpu 利用率不高于 60% 下的最大并发数”。但此处并没有具体测试场景。
因此此处仅通过持续增加系统负载，来测试系统性能的变化，测试目的包含：
- 测试系统所能承受的最大负载量
- 找出指标阈值下的系统瓶颈和性能拐点
- 找出内存管理错误，内存泄漏，缓冲区溢出的问题
- 找到处理极限，为调优提供数据
- 找出系统在稳定情况下的最大压力值
5.2.2 测试场景
5.2.2.1 单一功能
配置: 线程200，启动时间1，永久循环，通过RPS逐步稳定提升功能负载，测试功能“资产->创建记账单位”性能瓶颈、性能拐点、CPU、内存等情况。
.png)
.png)
第一次测试结果.png)
.png)
.png)
.png)
第二次测试结果.png)
.png)
.png)
.png)
第三次测试结果.png)
.png)
.png)
.png)
.png)
.png)
测试结果描述和分析:
- TPS：
__依据情况填写__ - 响应时间：
__依据情况填写__ - 错误率:
__依据情况填写__ - CPU负载：
__依据情况填写__ - 内存负载：
__依据情况填写__ - 磁盘负载：
__依据情况填写__
5.2.2.2 混合功能
配置: 线程10min内增长到120，持续运行一段时间，通过线程逐步稳定提升功能负载，测试多个功能下性能瓶颈、性能拐点、CPU、内存等情况。
.png)
.png)
.png)
.png)
.png)
.png)
.png)
测试结果描述和分析:
- TPS：
__依据情况填写__ - 响应时间：
__依据情况填写__ - 错误率:
__依据情况填写__ - CPU负载：
__依据情况填写__ - 内存负载：
__依据情况填写__ - 磁盘负载：
__依据情况填写__
5.3 稳定性测试
5.3.1 测试方法
分为两类进行: ①阶梯加压 ②spike尖峰测试
测试目的:
- 测试系统的资源在饱和状态下的应用的处理会话能力
- 持续稳定的增加系统压力，测试系统性能的变化
- 破坏性测试，确保系统失败并能正常恢复
- 发现系统稳定性的隐患和系统在负载峰值的条件下功能隐患
- 关注大业务量情况系统的长时间运行状态（例如反应变慢、内存泄漏 系统崩溃、失效恢复）
- 找出系统在可控错误率下的最大压力值
5.3.2 测试场景
5.3.2.1 阶梯加压
- 通过执行 8 小时（也可以是 4、6、12、24、24*7 等，根据实际情况）的方式，监控服务器资源消耗（特别是核心进程的内存消耗）、数据库处理能力等。稳定性测试负载压力可以采用系统最大处理能力的 70% 或 80%，或混合场景中某个压力值。
5.3.2.2 Spike尖峰测试
反复冲击服务器，看服务器是否能从从高负荷中恢复并正常工作。
.png)
.png)
.png)
.png)
.png)
.png)
.png)
测试结果描述和分析:
- TPS：
__依据情况填写__ - 响应时间：
__依据情况填写__ - 错误率:
__依据情况填写__ - CPU负载：
__依据情况填写__ - 内存负载：
__依据情况填写__ - 磁盘负载：
__依据情况填写__
5.4 破坏性测试
5.4.1 测试方法
通过不断加压，直至系统奔溃，从而观察系统的最大承受能力和期间所暴露出来的问题
5.4.2 测试场景
构建一个梯级场景，每X秒（5s）增加Y（100个）个并发，高负载情况下持续运行一段时间，然后降低负载。
.png)
.png)
.png)
.png)
.png)
测试结果描述和分析:
- TPS：
__依据情况填写__ - 响应时间：
__依据情况填写__ - 错误率:
__依据情况填写__ - CPU负载：
__依据情况填写__ - 内存负载：
__依据情况填写__ - 磁盘负载：
__依据情况填写__
5.5 其它测试
5.5.1 顺序场景测试
| 业务名称 | 接口地址 | 请求类型 | 参数 |
|---|---|---|---|
| 功能A1 | http://192.168.1.110/a1 | post | 略 |
| 功能A2 | http://192.168.1.110/a2 | post | 略 |
| 功能A3 | http://192.168.1.110/a3 | post | 略 |
.png)
.png)
测试结果描述和分析: __依据情况填写__
5.5.2 瞬时并发测试
瞬时并发1000个请求
.png)
.png)
测试结果描述和分析: __依据情况填写__
6.测试结论
问题:
- 问题1
- 问题2
建议：
- 建议1
- 建议2
7.记录一下测试过程中发现问题和解决方法
7.1 【问题1】线程阻塞 发现、分析、解决、结果、其它问题 过程
- 步骤1: 在5.2.2.1 的测试结果中，发现等待队列偶尔持续超过cpu个数。
- 步骤2: 在通过arthas的thred -b分析哪个java文件阻塞。
.png)
.png)
- 步骤3: 通过修改XXX.java代码解决问题。
- 步骤4: 重新压测，看TPS是否有上升 (若已超过主测试机性能，使用分布式压测测试)
7.2 【问题2】程序长期运行或长期压测，会出现内存溢出OOM， 记录 发现、分析、解决、结果、其它问题 过程
- 步骤1: 压测程序和长时间运行程序，发现内存持续缓慢升高
.png)
.png)
.png)
- 步骤2: 分析:
- 通过jprofiler监控内存堆栈的变量，看是否有很大的内存占用，尝试执行GC，看内存是否恢复，如果能恢复，即没问题，如果不能恢复，可能是堆外内存问题。
- 通过arthas分析内存上升的地方，发现g1_eden_span会占用一部分内存【需要重新设置一下-XX:G1HeapRegionSize=1024m】。但这部分内存是可以被GC的，所以不是主要原因。
- 设置-XX:G1HeapRegionSize=1024m会限制netty的堆外内存，如果内存还是持续升高，就要考虑是有原生jni插件占用内存了
- 通过jemalloc分析堆外内存
- 得出结果
.png)
- 修复代码
- 重新测试
相关链接
- 写报告
https://blog.csdn.net/sha_123456789/article/details/106247986 https://www.cnblogs.com/dayu2019/p/11649300.html https://zhuanlan.zhihu.com/p/578068713
