性能测试报告
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) 内存占用处于高位水平,需要进一步探查原因。