关于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日

目录

一、测试内容

二、测试方法

1.测试方式描述。

2、 简述测试步骤。

2.1设置请求默认地址：图示设置默认路径为 XXXXX

2.2设置请求XXXX路径及相关参数

2.3设置响应事件结果图

2.4设置表格展示结果

3、测试指标提取:

三、测试目标

四、测试环境

1.测试客户端配置

2.网络环境

3.测试时间

五、系统部署

六、测试说明

七、测试统计及分析

1)50个线程组并发

2)100个线程组并发

3)200个线程组并发

4)500个线程组并发

5)1000个线程组并发

6)2000个线程组并发

7)3000个线程组并发

8)4000个线程组并发

八、结果

九、结论及建议

一、测试内容

本次测试是针对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及内存或作负载均衡，方可维护服务的稳定。