关于XXXX生产环境压测报告
文章目录
修订历史 | ||||
---|---|---|---|---|
所属部门 | 版本号 | 编制修改原因 | 人员 | 修改日期 |
XXXXX | 001 | 创建 | XXXXX | XXXX年XX月XX日 |
XXXXX | 002 | 修订 | XXXXX | XXXX年XX月XX日 |
XXXXX | 003 | 修订 | XXXXX | XXXX年XX月XX日 |
XXXXX | 004 | 修订 | XXXXX | XXXX年XX月XX日 |
XXXXX | 005 | 评审 | XXXXX | XXXX年XX月XX日 |
目录
一、测试内容
本次测试是针对XXXXX系统服务进行的压力测试,本次压测主要提取XXXXX进行压力测试。
二、测试方法
1.测试方式描述。
本次采用apache的开源测试工具Jmeter,采用Jmeter代理服务器录制脚本生成http请求脚本,并通过http协议post方式发送访问请求,收集服务器响应速度等情况。
2、简述测试步骤。
安装启动JMeter,分别对以上页面进行压力测试分别测试50、100、500、1000、2000、3000、4000个线程,即模拟这些数目的用户并发; Ramp-up period(inseconds)的值设为1(即1s启动50、100、500、1000、2000、3000、4000并发访问),并发持续运行为5分钟。
2.1设置请求默认地址:图示设置默认路径为XXXXX
2.2设置请求XXXX路径及相关参数
图示请求无消息体内容(下面是展示消息体Json格式):
{
"orderNo": "AAAA",
"areaId": 123456,
"updatetDate": "2022-10-14",
"createDate": "null",
"mobile": "12345678911",
"userId": 2,
"address":{
"city":330300,
"street":"aaaa"
}
}
2.3设置响应事件结果图
2.4设置表格展示结果
3、测试指标提取:
测试项 | 并发数 | 持续运行时间 | 响应时间最小 | 响应时间最大 | 平均响应时间 | 成功率 | 总请求量 | 吞吐量 |
---|---|---|---|---|---|---|---|---|
系统入口 | 50 | 5min | <1s | <2min | <20s | 100% | >80000 | >200.0/sec |
100 | 5min | <1s | <2min | <20s | 100% | >80000 | >200.0/sec | |
200 | 5min | <1s | <2min | <20s | 100% | >80000 | >200.0/sec | |
500 | 5min | <1s | <2min | <20s | 100% | >80000 | >200.0/sec | |
1000 | 5min | <1s | <2min | <20s | 100% | >80000 | >200.0/sec | |
2000 | 5min | <1s | <2min | <20s | 100% | >80000 | >200.0/sec | |
3000 | 5min | <1s | <2min | <20s | 100% | >80000 | >200.0/sec | |
4000 | 5min | <1s | <2min | <20s | 100% | >80000 | >200.0/sec |
三、测试目标
XXXX服务服务器器极限值
四、测试环境
1.测试客户端配置
主机用途 | 机型/OS | 台数 | CPU/台 | 内存容量/台 |
---|---|---|---|---|
模拟用户请求 | Windows | 2 | 8 | 16G |
2.网络环境
本次测试是在公网中进行的测试,更能模拟用户操作环境,可以会对压测造成影响。
3.测试时间
压测环境 | 测试人 | 测试时间 |
---|---|---|
XXXX生产环境 | XXXX | 2022年10月14日 |
五、系统部署
系统已经经过开发人员部署在虚机上,无需另外再次进行系统部署。
六、测试说明
名词定义(时间的单位均为ms):
样本----本次场景中一共完成了多少个线程
平均值----平均响应时间
中位数----50%请求的响应时间
90%百分位----90%请求响应时间
95%百分位----95%请求响应时间
99%百分位----99%请求的响应时间
最小值----最小的响应时间
最大值----最大的响应时间
异常%----错误率=错误的请求的数量/请求的总数
吞吐量----吞吐量即表示每秒完成的请求数
接收 KB/sec----每秒从服务器端接收到的数据量
发送 KB/sec----每秒从客户端发送的请求的数量
七、测试统计及分析
压测场景:
1.输入URL:XXXXX
1)50个线程组并发
聚合报告
并发50个用户,持续运行5分钟,完成71036次访问请求,最小响应速度为37ms,最大为2815ms,平均响应速度为210ms,与预期的快,访问成功率100%,符合预期的需求。
从下图可以看出从开始压测,并持续运行5分钟到结束,总共处理请求71036个,几乎所有请求的响应时间都在1秒左右,符合预期。
2)100个线程组并发
聚合报告
并发100个用户,持续运行5分钟,完成89001次访问请求,最小响应速度为36ms,最大为2050ms,平均响应速度为336ms,吞吐量在293.5/sec,比预期的快,访问成功率100%,符合预期的需求。
从下图可以看出从开始压测,并持续运行5分钟到结束,总共处理请求89001个,几乎所有请求的响应时间都在1秒左右,符合预期。
3)200个线程组并发
聚合报告
并发200个用户,持续运行5分钟,完成95803次访问请求,最小响应速度为55ms,平均响应速度在1秒内,与预期的快,访问成功率100%,符合预期的需求。
从下图可以看出从开始压测,并持续运行5分钟到结束,总共处理请求95803个,几乎所有请求的响应时间都在2秒内,符合预期。
4)500个线程组并发
聚合报告
并发500个用户,持续运行5分钟,完成102473次访问请求,最小响应速度为88ms,最大为5188ms,平均响应速度为1462ms,并且吞吐量达到为340.7/sec,比预期的快,访问成功率100%,符合预期的需求。
从下图可以看出从开始压测,并持续运行5分钟到结束,总共处理请求102473个,几乎所有请求的响应时间都在3秒左右,符合预期。
5)1000个线程组并发
聚合报告
并发1000个用户,持续运行5分钟,完成17871次访问请求,最小响应速度为173ms,最大在15秒以内,平均响应速度为3290ms,与预期的快,访问成功率100%,符合预期的需求。
从下图可以看出从开始压测,并持续运行5分钟到结束,总共处理请求91420个,百分之90的请求响应时间在5秒以内,符合预期。
6)2000个线程组并发
聚合报告
并发2000个用户,持续运行5分钟,完成92777次访问请求,最小响应速度为365ms,最大在30秒以内,平均响应速度为6.5秒,与预期的快,访问成功率100%,符合预期的需求。
从下图可以看出从开始压测,并持续运行5分钟到结束,总共处理请求92777个,百分之95的请求在10秒左右响应,符合预期。
7)3000个线程组并发
聚合报告
并发3000个用户,持续运行5分钟,完成91124次访问请求,最小响应速度为809ms,平均响应速度在10秒内,吞吐量为298.0/sec与预期的快,访问成功率100%,符合预期的需求。
从下图可以看出从开始压测,并持续运行5分钟到结束,总共处理请求91124个,百分之90的请求在15秒左右响应,符合预期。
8)4000个线程组并发
聚合报告
并发4000个用户,持续运行5分钟,完成80037次访问请求,最小响应速度为311ms,平均响应速度在15秒左右,百分之90的请求在30秒以内响应,比预期的快,访问成功率97.67%,符合预期的需求。
从下图可以看出从开始压测,并持续运行5分钟到结束,总共处理请求80037个,在开始一分钟时达到第一个峰值,表示请求挤压一定的时间,系统处理请求变得缓慢,此时jmeter发送的请求也变少,系统将积压的请求处理完成,到开始两分钟节点时,第二个峰值到来,响应时间由于系统一直处理高压事态,当jmeter发送请求略微变快,系统开始报错,但是百分之90的请求在30秒以内响应,符合预期。
八、结果
压测结果:
测试项 | 并发数 | 持续运行时间 | 响应时间最小 | 响应时间最大 | 平均响应时间 | 成功率 | 总请求量 | 吞吐量 | 是否符合预期 |
---|---|---|---|---|---|---|---|---|---|
预期结果 | 50-4000 | 5min | <1s | <2min | <20s | 100% | >80000 | >200.0/sec | * |
系统XXXX实际结果 | 50 | 5min | 37ms | 2815ms | 210ms | 100% | 71036 | 236.7/sec | 符合预期 |
系统XXXX实际结果 | 100 | 5min | 36ms | 2050ms | 336ms | 100% | 89001 | 296.5/sec | 符合预期 |
系统XXXX实际结果 | 200 | 5min | 55ms | 9632ms | 625ms | 100% | 95803 | 319.0/sec | 符合预期 |
系统XXXX实际结果 | 500 | 5min | 88ms | 5188ms | 1462ms | 100% | 102473 | 340.7/sec | 符合预期 |
系统XXXX实际结果 | 1000 | 5min | 173ms | 14390ms | 3290ms | 100% | 91420 | 302.7/sec | 符合预期 |
系统XXXX实际结果 | 2000 | 5min | 365ms | 27540ms | 6474ms | 100% | 92777 | 306.6/sec | 符合预期 |
系统XXXX实际结果 | 3000 | 5min | 809ms | 113810ms | 9975ms | 100% | 91124 | 298.0/sec | 符合预期 |
系统XXXX实际结果 | 4000 | 5min | 311ms | 347362ms | 15489ms | 97.67% | 80037 | 165.9/sec | 不符合预期 |
九、结论及建议
1.结论:
并发50-3000之间,持续时间5min,响应最小时间在一秒以内,平均时间在20秒以内,成功率100%,总请求在80000以上,吞吐量大于200/sec。压测发现硬件CPU及内存存在不足,并发数在2000时,请求的平均响应时间为30秒以内,平均每秒处理306个请求,但是当并发增加到了3000个时,服务器的平均响应速度变得很慢,但是每秒依旧处理将近300个请求,但是当并发到达4000个时,系统大量请求挤压,响应时间最长达5分钟,并且出现异常,系统每秒处理的请求数量也急剧下降到165个请求,如果此时大量请求持续进来,系统将宕机。
PS:该服务器还有一些其他服务运行这占有一定的CPU及内存对数据结果是存在一定的影响的。所以此数据只能作为参考值来看。
2.建议:
依照目前生产服务情况达到每秒3000并发,每秒吞吐量298.0将是极限,建议增加CPU及内存或作负载均衡,方可维护服务的稳定。