性能报告,性能测试报告模板"/>
服务器申请性能报告,性能测试报告模板
性能测试报告
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) 内存占用处于高位水平,需要进一步探查原因。
内容来源于网络如有侵权请私信删除
更多推荐
服务器申请性能报告,性能测试报告模板
发布评论