Jmeter压力测试报告案例

《xxxxxx》监测服务压力测试报告

 

 

文档修订记录

 

 

版本号

日期

修改人

摘要

V1.0

2019年8月14日

xxx

初稿

























 



内容目录






 

一、测试内容

 

本次测试是针对《xxxx数字化营销》系统内的监测服务进行的压力测试,本次压测主要提取广告监测代码进行压测:广告监测服务。

二、测试方法

1.本次采用apache的开源测试工具jmeter，采用jmeter代理服务器录制脚本生成http请求脚本,并通过http协议get方式发送访问请求,收集服务器响应速度,服务器资源耗用情况。

2、安装启动JMeter,分别对以上页面进行压力测试分别测试50、100、500、1000个线程，即模拟这些数目的用户并发; Ramp-up period(inseconds)的值设为1(即1s启动50、100、500、1000并发访问),并发持续运行为10分钟。

3、测试指标提取:

测试项

并发数

线程组增量

持续运行时间

响应时间

成功率

CPU使用率

内存使用率







广告监测服务

50

每秒增加10个

10分钟

≤5分钟

99%









75%









70%

100

每秒增加100个

10分钟

≤5分钟

99%

200

每秒增加200个

10分钟

≤5分钟

99%

500

每秒增加500个

10分钟

≤5分钟

99%

1000

每秒增加1000个

10分钟

≤5分钟

99%

 

三、测试目标

一台广告监测服务器极限值

四、测试环境

1.系统环境配置

主机用途

机型/OS

台数

CPU/台

内存容量/台

对应IP

应用服务器

 

1

2 CPU

4GB

公网：xxx

内网：xxx

数据库服务器

同上

同上

同上

同上

同上

 

2.测试客户端配置

 

 

主机用途

机型/OS

台数

CPU/台

内存容量/台

对应IP

压力负载生成器

xxx

1

2

8G

xxx

3网络环境

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

4.测试时间

压测环境

测试人

测试时间

2CPU 4GB内存

xxxxx

2019年8月14

五、系统部署

系统已经经过开发人员部署在xxxxxx这台机子上,无需另外再次进行系统部署。

访问网址：XXXXX

六、测试说明

名词定义(时间的单位均为ms):

Samples – 本次场景中一共完成了多少个线程

Average – 平均响应时间

Median----50%请求的响应时间

90%Line----90%请求响应时间

95%Line----95%请求响应时间

99%Line----99%请求的响应时间

Min----最小的响应时间

Max----最大的响应时间

Error%----错误率=错误的请求的数量/请求的总数

Throughput----吞吐量即表示每秒完成的请求数

Received KB/sec----每秒从服务器端接收到的数据量

Sent KB/sec----每秒从客户端发送的请求的数量

七、测试统计及分析

压测场景：

1.输入URL：xxxxxxx

2.2CPU 4GB内存压力统计

1)50个线程组并发

聚合报告

并发50个用户,持续运行10分钟,完成1426013次访问请求,最小响应速度为0.004秒,最大为3.688秒,平均响应速度为0.02秒,与预期的快近4秒多,访问成功率100%,符合预期的需求。

系统资源耗用

从13：22开始压测,持续运行10分钟13：32结束，CPU使用率主要维持在45%—85%之间,整体趋势图来看与预期的小于75%略显偏高;内存(Memory)使用率75%左右,与预期小于70%,总体不符合需求。

 

 

2)100个线程组并发

聚合报告

并发100个用户,持续运行10分钟,完成1418887次访问请求,最小响应速度为0.004秒,最大为27.009秒,平均响应速度为0.042秒,与预期的快了近4秒多,访问成功率100%,符合预期的需求。

系统资源耗用

 

从13：37开始压测,持续运行10分钟13：47结束，CPU使用率主要维持在40%—85%之间,整体趋势图来看与预期的小于75%略显偏高;内存(Memory)使用率75%左右,与预期等于70%,总体不符合需求。

 

3)200个线程组并发

聚合报告

并发200个用户,持续运行10分钟,完成1452045次访问请求,最小响应速度为0.004秒,最大为367.546秒,平均响应速度为0.082秒,与预期的快4秒多,访问成功率100%,符合预期的需求。

系统资源耗用

 

从14：32开始压测,持续运行10分钟14：42结束，CPU使用率主要维持在65%—85%之间,整体趋势图来看与预期的小于75%略显偏高;内存(Memory)使用率75%左右,与预期70%略显偏高,总体不符合需求。

 

4)500个线程组并发

聚合报告

并发500个用户,持续运行10分钟,完成1334830次访问请求,最小响应速度为0.004秒,最大为417.365秒,平均响应速度为0.224秒,与预期的还快4秒,访问成功率99.99999%,符合预期的需求。

系统资源耗用

 

从14：48开始压测,持续运行10分钟14：58结束，CPU使用率主要维持在63%—87%之间,整体趋势图来看与预期的小于75%略显偏高;内存(Memory)使用率75%左右,与预期70%略显偏高,总体不符合需求。

 

5)1000个线程组并发

聚合报告

并发1000个用户,持续运行10分钟,完成1289467次访问请求,最小响应速度为0.004秒,最大为597.21秒,平均响应速度为0.464秒,与预期的还快4秒,访问成功率99.99998%,符合预期的需求。

系统资源耗用

 

从15：08开始压测,持续运行10分钟15：18结束，CPU使用率主要维持在45%—85%之间,整体趋势图来看与预期的小于75%略显偏高;内存(Memory)使用率75%左右,与预期70%略显偏高,总体不符合需求。

 

针对广告监测动态统计

并发线程数

#Samples

Average

90%Line

Min

Max

Error%

Throughput

50

1426013

20

11

4

3688

0.00%

2374.7/sec

100

1418887

42

22

4

27009

0.00%

2359.4/sec

200

1452045

82

212

4

367546

0.00%

2416.9/sec

500

1334830

224

625

4

417365

0.01%

2222.5/sec

1000

1289467

464

1039

4

597210

0.02%

2144.2/sec

八、结果

2cpu 4GB内存压测:

测试项

并发数

线程组增量

持续运行时间

响应时间(ms)

成功率

CPU使用率

内存使用率







广告监测服务

50

每秒增加50个

10分钟

20

100%

45%—85%之

75%

100

每秒增加100个

10分钟

42

100%

40%—85%

75%

200

每秒增加200个

10分钟

82

100%

65%—85%

75%

500

每秒增加500个

10分钟

224

99.9999%

63%—87%

75%

1000

每秒增加1000个

10分钟

464

99.9998%

45%—85%

75%

九、结论及建议

1.结论：

2cpu 4GB内存压测:当压测开始发现硬件CPU及内存存在不足,并发数增加到了500个,服务器的平均响应速度变得慢,并且开始有数据请求失败cpu及内存是个瓶颈。

PS：该服务器还有一些其他服务运行这占有一定的CPU及内存对数据结果是存在一定的影响的。所以此数据只能作为参考值来看。

2.建议：

依照目前服务情况达到500将是极限，建议增加CPU及内存或作负载均衡，方可维护服务的稳定，目前硬件配置为2CPU ，4GB内存。

 

 

 

 

posted @ 2019-08-19 11:18  zxywaiting  阅读(25122)  评论(5)  编辑  收藏  举报