负载测试场景
负载测试:逐步增加并发用户数,拐点区间
jmeter如何逐步增加并发用户数:
安装jpgc - Standard Set
插件
![jpgc](https://img-blog.csdnimg.cn/img_convert/a95ac2c186efdfe002c0cf2a1a4c33f6.png)
在「测试计划」右键添加「线程」的时候可以发现多了很多项
![线程](https://img-blog.csdnimg.cn/img_convert/1a1625f05b23171d252c87e46e47c31d.png)
选择「jp@gc - Stepping Thread Group (deprecated)」
![](https://img-blog.csdnimg.cn/img_convert/1adf56800a790b9661805a02de1fb4b5.png)
x轴:时间
y轴:用户数
![配置](https://img-blog.csdnimg.cn/img_convert/0da0a3bd68f691a5b62de41ebba8884a.png)
This group will start 「100」 threads:将启动100个线程数
First,wair for 「0」 seconds:首先等待0秒
Then start 「0」threads:然后 启动0个用户
Next,add「10」 threads every 「30」seconds,using ramp-up 「5」 seconds:每5秒钟,增加10个线程数,然后运行30秒
Then hold load for 「60」seconds:然后持续运行60秒
Finally,stop「5」threads every 「1」 seconds:最后,没1秒停止5个线程数
![图讲解](https://img-blog.csdnimg.cn/img_convert/2ae065f7574896f2923e4963a65ef01f.png)
缓起步,快结束
结束时间不能太短,也不能太长
太短:可能导致出错,这个出错是场景设计的问题,不是性能问题
太长:导致性能指标值与实际值偏差太大
如果330正常,在360出现异常,出现拐点区间。
所以拐点范围为[330,360]
,通过缩小范围,找到拐点值
![寻找拐点](https://img-blog.csdnimg.cn/img_convert/060fd14b8ea76899150133afa5844df6.png)
![寻找拐点](https://img-blog.csdnimg.cn/img_convert/e5447c5c11e7d48c3c2669a33c44aae9.png)
想要寻找某个接口的最大并发用户数,通过最大并发用户数,获取性能指标值?
设置一个阶梯线程组,自己设置一个最大值
运行,找到拐点值
缩小拐点区间,找到最大并发用户数
进行性能测试
如何找到拐点值
在添加插件后可以看到「监听器」中新增了部分内容
![监听器](https://img-blog.csdnimg.cn/img_convert/b5bb022979de84eb6d03f1a6947365d2.png)
Active Threads Over Time:随着时间变化的活跃线程数
PerfMon Metrics Collecotr:性能监控器
Response Times Over Time:随着时间变化的响应时间
Transactions per Second:TPS
![线程组](https://img-blog.csdnimg.cn/img_convert/14a41a420d80bb9f8dbe94024961f582.png)
Active Threads Over Time
![Active Threads Over Time](https://img-blog.csdnimg.cn/img_convert/43dc9cfd2dd2c0b5bff06c561ca5f351.png)
Response Times Over Time
![Response Times Over Time](https://img-blog.csdnimg.cn/img_convert/39f8c0108444fa8a53c8208a5980d5b8.png)
Transactions per Second]
![Transactions per Second](https://img-blog.csdnimg.cn/img_convert/dbd479a3fab1c3a8c6cccc1a9ca47956.png)
是否有报错
响应时间是否超过1.5s:用户满意度指数:500ms是可以接受,超过1.5s不能接受
tps 不上升,反而下降
响应时间+活跃线程数=>不同线程数时的平均响应时间
活跃线程数+TPS=>不同线程数的平均tps
注意:一般不会在一个线程组下挂载多个接口,因为 监听器图标中,会把所有接口数据合并在一个图标中,数据太多,不利于分析
![多个接口](https://img-blog.csdnimg.cn/img_convert/1e83d34554bc5b27a0de375ba12af45d.png)
压力测试场景
持续运行比较长时间,看服务器的稳定性
普通线程组:调度器持续运行时间,设置比较长
阶梯线程组:hold load时间设置比较长
![hold load](https://img-blog.csdnimg.cn/img_convert/5bd8d18aeca6341d71f6be944876b7c6.png)
面向目标的场景
需求:有一个页面,需要做性能测试。看能否支持一秒钟5000人访问
相当于:1秒钟要处理500人的请求事务=>500tps
一般的公司,接口tps范围数50~200
添加一个「bzm - Arrivals Thread Group」
![bzm - Arrivals Thread Group](https://img-blog.csdnimg.cn/img_convert/d66fda054e8b763b9f3befd20c74fcad.png)