性能测试报告
Performance Test Report
| 项目 |
XXX项目二期 |
| 版本 |
V1.00 |
| 作者 |
dayu |
| 日期 |
2019.9.31 |
1. 测试概述
1.1 测试目标
描述本次测试的意义和目标
本次测试的目的在于探查XXX项目二期重构环境的系统业务处理性能，以及在高负载情况下的系统表现。
1.2 指标和术语
描述本次测试中涉及到的性能指标术语
| 术语 |
释义 |
| 并发数 |
测试时同时系统发出事务请求的数量，并发线程数用以模拟同时与系统建立连接的用户。 |
| TPS（每秒事务数） |
在每秒时间内系统可处理完毕的事务数。TPS很大程度体现系统性能能力。 |
| 错误率 |
经系统处理的事务出现错误的概率，对应着实际用户使用系统功能失败的情况。理想情况下错误率应保持极低水平。 |
| 资源占用率 |
服务器端各关键资源的使用比例，用于衡量系统硬件能力 |
2. 环境、工具
列出本次测试所涉服务器、客户机和测试工具
2.1 测试环境
服务器：
| 应用 |
机器 |
CPU、内存配置 |
| API |
ip地址 |
16核CPU、内存16G |
| MYSQL |
ip地址 |
16核CPU、内存16G |
客户机：
| 操作系统 |
CPU |
内存 |
| Windows10 专业版 |
I3- 4170 3.70GHZ |
8G |
2.2 测试工具
| 核心工具 |
版本 |
备注 |
| Jmeter |
3.3 |
提供并发请求能力 |
| PerfMon Metrics Collector |
2.1 |
Jmeter插件，用于收集服务器资源使用信息 |
| ServerAgent |
2.2.1 |
以伺服形式发送服务器资源使用信息 |
| nMon |
16h v2 |
实时收集服务器资源信息 |
3. 测试方案
3.1 测试类型
不同的性能测试场景可能使用不同的测试类型，需要明确
本次性能测试将主要采用以下几种测试类型：
l 基准测试：
在小并发条件下，探测系统各性能指标表现，作为后续比对基础。
l 压力测试：
由于无法准确预估用户访问量，因此考虑使用压力测试方法。压力测试旨在通过不断 增加系统并发处理事务数，增加系统负载，直到系统到达性能瓶颈。以此推算出系统 可承载用户和事务请求数。
l 稳定性测试：
将系统置于较长时间高负载场景下，探测系统是否出现稳定性缺陷。
3.2 业务模型
针对系统接口，究竟哪些需要被纳入压测范畴？不同事务应该以何种比例被调用，这是需要建模设计的，也是性能测试的难点之一。
通过对于项目架构和业务场景分析，设计以下业务模型进行模拟和测试：
场景1：简单业务场景
| 业务名称 |
接口地址 |
请求类型 |
并发比例 |
| 登录 |
/login |
post |
1 |
| 查询用户信息 |
/queryMemberInfo |
get |
1 |
场景2：混合业务场景
| 业务名称 |
接口地址 |
请求类型 |
并发比例 |
| 登录 |
/login |
post |
1 |
| 查询用户信息 |
/queryMemberInfo |
get |
1 |
| 交易查询 |
/listOrderPage |
get |
1 |
| 订单创建 |
/createOrder |
post |
1 |
3.3 加密验签处理
由于系统对于所有事务请求都进行了加密验签处理，因此在本次性能测试中，需要对请求报文进行一致的加密和签名。处理逻辑如下：
l 使用APP同样的加密签名代码，导出jar包做为加密工具类
l 使用jmeter前置处理器-beanshell处理器调用上述jar包方法实现请求参数加密
l 将加密签名后的请求参数存储为变量，后续接口调用时使用
3.4 压力梯度
对于3.2所述场景，分别进行梯度加压，从100并发开始，每次递增100并发数，直至到达系统瓶颈。
4. 测试结果
4.1 聚合报告
| 标签 |
样本数 |
平均（响应时间ms） |
最小 |
最大 |
错误率 |
吞吐量（/s） |
| 登录 |
50 |
28 |
20 |
38 |
0.00% |
4.5977 |
| 查询member信息 |
50 |
1602 |
1292 |
2042 |
0.00% |
4.07133 |
| 查看交易 |
50 |
705 |
512 |
920 |
0.00% |
4.37828 |
| 创建订单 |
50 |
86 |
60 |
119 |
0.00% |
4.55083 |
| 总体 |
200 |
605 |
20 |
2042 |
0.00% |
15.11716 |
场景1-10并发-循环5次
| 标签 |
样本数 |
平均（响应时间ms） |
最小 |
最小 |
错误率 |
吞吐量（/s） |
| 登录 |
500 |
7612 |
40 |
26725 |
0.00% |
15.84987 |
| 查询用户信息 |
500 |
30871 |
2369 |
49719 |
0.00% |
6.96233 |
| 总体 |
1000 |
19241 |
40 |
49719 |
0.00% |
13.91517 |
场景1-500并发-循环1次
| 标签 |
样本数 |
平均（响应时间ms） |
最小 |
最大 |
错误率 |
吞吐量（/s） |
| 登录 |
550 |
8326 |
33 |
22360 |
0.00% |
20.34851 |
| 查询用户信息 |
550 |
36071 |
4362 |
58485 |
0.36% |
6.7585 |
| 总体 |
1100 |
22199 |
33 |
58485 |
0.18% |
13.51069 |
场景1-550并发-循环1次
| 标签 |
样本数 |
平均（响应时间ms） |
最小 |
最大 |
错误率 |
吞吐量（/s） |
| 登录 |
4500 |
12408 |
87 |
46269 |
0.00% |
4.68807 |
| 查询用户信息 |
4500 |
35383 |
3792 |
65036 |
0.00% |
4.63027 |
| 查看交易 |
4500 |
22832 |
711 |
46812 |
0.02% |
4.64518 |
| 创建订单 |
4500 |
24973 |
81 |
58698 |
0.13% |
4.67591 |
| 总体 |
18000 |
23899 |
81 |
65036 |
0.04% |
18.50308 |
场景2-450并发-循环10次
4.2 系统吞吐量
场景1-550并发-循环1次
场景2-450并发-循环10次
4.3 资源占用率
最优负载条件下：
CPU使用率
内存占用率
磁盘使用率
5. 分析和建议
结合收集到的数据，给出对于系统性能关键点的分析
5.1 测试结论分析
经过多次测试和数据报表分析，可以得出如下结论：
1) 当总体并发用户数为450-500时，系统具有最优性能表现；当事务并发数超过500时，事务失败率整体上升，系统到达性能拐点。
2) 多事务混合条件下，系统巅峰TPS在90左右，平均吞吐量在13-18/s。
3) 在小压力条件下（10并发），最大事务响应时间为查询用户信息事务的2042毫秒，平均在600毫秒左右系统。整体事务微观响应速度较优。
4) 满负载条件下，登录具有最佳的性能表现，平均响应时间为7000-12000毫秒；查询用户信息事务性能较差，平均响应时间在30000-40000区间。满负载条件下系统整体微观响应时间较差。查询用户接口由于其使用极为频繁，建议进行SQL效率调优
5) 系统资源方面，内存占用率始终处于高位水平（90%以上），磁盘空间由于日志写入而不断被占用。
5.2 问题
测试过程中发现了如下显著问题：
1) 加密验签功能并未生效-现阶段任何签名均可通过验签。属于功能性问题，不影响性能表现。
2) 日志文件由于不断写入导致磁盘占满，建议调低系统日志级别，并做好定期日志备份。
3) 内存占用处于高位水平，需要进一步探查原因。