2、企业级Jmeter压力测试方法及报告模板

关于XXXX生产环境压测报告

文章目录

修订历史所属部门版本号编制修改原因人员****修改日期XXXXX001创建XXXXXXXXX年XX月XX日XXXXX002修订XXXXXXXXX年XX月XX日XXXXX003修订XXXXXXXXX年XX月XX日XXXXX004修订XXXXXXXXX年XX月XX日XXXXX005评审XXXXXXXXX年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、测试指标提取:

测试项并发数持续运行时间响应时间最小响应时间最大平均响应时间成功率总请求量吞吐量系统入口505min<1s<2min<20s100%>80000>200.0/sec1005min<1s<2min<20s100%>80000>200.0/sec2005min<1s<2min<20s100%>80000>200.0/sec5005min<1s<2min<20s100%>80000>200.0/sec10005min<1s<2min<20s100%>80000>200.0/sec20005min<1s<2min<20s100%>80000>200.0/sec30005min<1s<2min<20s100%>80000>200.0/sec40005min<1s<2min<20s100%>80000>200.0/sec

三、测试目标

XXXX服务服务器器极限值

四、测试环境

1.测试客户端配置

主机用途机型/OS台数CPU/台内存容量/台模拟用户请求Windows2816G

2.网络环境

本次测试是在公网中进行的测试,更能模拟用户操作环境，可以会对压测造成影响。

3.测试时间

压测环境测试人测试时间XXXX生产环境XXXX2022年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-40005min<1s<2min<20s100%>80000>200.0/sec*系统XXXX实际结果505min37ms2815ms210ms100%71036236.7/sec符合预期系统XXXX实际结果1005min36ms2050ms336ms100%89001296.5/sec符合预期系统XXXX实际结果2005min55ms9632ms625ms100%95803319.0/sec符合预期系统XXXX实际结果5005min88ms5188ms1462ms100%102473340.7/sec符合预期系统XXXX实际结果10005min173ms14390ms3290ms100%91420302.7/sec符合预期系统XXXX实际结果20005min365ms27540ms6474ms100%92777306.6/sec符合预期系统XXXX实际结果30005min809ms113810ms9975ms100%91124298.0/sec符合预期系统XXXX实际结果40005min311ms347362ms15489ms97.67%80037165.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及内存或作负载均衡，方可维护服务的稳定。