Jmeter@场景负载加压

目录

性能测试Jmeter,常用的主流场景

场景一:Thread Group

场景二、jp@gc - Stepping Thread Group

场景三、jp@gc - Ultimate Thread Group

场景四、bzm - Concurrency Thread Group

场景五、bzm - Arrivals Thread Group

场景六:bzm - Free-Form Arrivals Thread Group


场景一:Thread Group

参数配置-线程属性Thread Properties:
1.线程数(Number of Threads):运行的线程数设置,一个线程对应一个虚拟用户,即并发数,多个线程模仿对服务器的并发访问

2.Ramp-up Period(in Seconds):所有线程数在多少秒内全部启动
不建议太短:会给服务器太大的压力
不建议太长:可能第一个线程执行完毕后,再执行第二个线程,达不到并发效果

3.循环次数(Loop Count):每个线程的重复运行次数
勾上永远,表示如果不停止将会一直执行下去

4. Delay Thread creation until needed :
默认情况下,测试开始的时候,所有线程就被创建完了。
如果勾选了此选项,那么线程只会在合适的需要用到的时候创建

参数配置-调度器配置Thread Properties【Scheduler-Configuration】:

1、持续时间(秒)-Duration(秒):测试持续的时间,如果启动时间+持续时间>结束时间,那么此设置覆盖结束时间

2、启动延迟(秒)-Startup delay(秒):点击执行按钮后,仅初始化场景,不运行线程,等待延迟到时后开始运行线程,如果开始点击执行按钮的时间+延迟时间>启动时间,则此设置覆盖启动时间

截图例子配置:

Number of Threads设置100个线程

Ramp-Up Period设置10--->每秒就会启动100/10=10个线程

Loop Count设置1 --->执行1次

Delay Thread creation until needed 勾选上--->每秒启动10个线程,并开始运行

Scheduler-Duration设置60--->持续执行60秒

Scheduler-Startup delay设置3--->延后启动3秒

场景二、jp@gc - Stepping Thread Group

Stepping Thread Group的特性
1.有预览图显示估计的负载
2.可延迟启动线程组
3.可持续增加线程负载
4.可设置最大负载的持续运行时间
Stepping Thread Group的作用
1.减少服务器的瞬时压力,做性能测试应该逐步增加压力,而不是瞬时加压
2.逐步增压越平缓越好,更容易从结果看到多少压力值下,有性能瓶颈

this group will start:表示总共要启动的线程数;若设置为 100,表示总共会加载到 100 个线程
first,wait for:从运行之后多长时间开始启动线程;若设置为 1 秒,表示运行1秒后立即启动线程
then start:初次启动多少个线程;若设置为 1 个,表示初次启动1个线程
next add:之后每次启动多少个线程;若设置为 5个,表示每个梯次启动 5 个线程
threads every:当前运行多长时间后再次启动线程,即每一次线程启动完成之后的持续时间;若设置为 25秒,每梯次启动完线程之后再运行 25秒
using ramp-up:启动线程的时间;若设置为 5 秒,表示每次启动线程都持续 5 秒
then hold load for:线程全部启动完之后持续运行多长时间,如图:设置为 300秒,表示 100 个线程全部启动完之后再持续运行 300秒
finally,stop/threads every:多长时间释放多少个线程;若设置为 5 个和 1 秒,表示持续负载结束之后每 1 秒钟释放 5 个线程

场景设置,与跑完的报告时间相吻合

 注:jp@gc - Throughput Shaping Timer

Throughput Shaping Timer 是用来控制吞吐量的定时器,通过延缓线程运行来整体控制取样器产生的RPS。
实际使用中:
1. 可以通过设置在不同吞吐量分别持续一段时间,考察系统在不同吞吐量情况下的稳定性
2. 可以通过设置随着时间持续增加的吞吐量,来探测系统吞吐量的的极限

jp@gc - Stepping Thread Group配置,如下:【设置100个线程数,一次启动10个,持续300秒】

整个场景运行时间为6分24秒

增加jp@gc - Throughput Shaping Timer定时器【设置RPS起始值】

RPS即每秒请求数(Request Per Second)

 最终场景运行1分13秒【探测系统吞吐量的的极限,很明显测试服务一点压力都没有,所以没有到服务器的极限】

 ​​​​​​

 同样的场景配置,设置两段定时器的RPS起始值

  最终场景运行1分13秒【设置在不同吞吐量分别持续一段时间,考察系统在不同吞吐量情况下的稳定性;执行过程中吞吐量持续上行,没有持续 或持平吞吐量,表现服务器比较稳定】

 比如一个请求响应时间为2秒,END RPS 为30,那么线程数:2*30=60  即:响应时间*RPS=所需线程数)。即大约要60个线程, 考虑到运行时诸多影响因素(线程数增加后响应时间增加了), 我们还需要预备更多的线程,也许我们加到70个线程才能满足要求,这只是一个估算值。

另外,线程组设置的循环是永远,但是因为有定时器的存在,脚本并不会停不下来,而是在定时器的时间结束后,脚本就会停止运行。

场景三、jp@gc - Ultimate Thread Group

【线性负载】

场景就比如说,春运抢票,这个时候系统30秒内涌入了10个用户并发,他们访问系统持续时间30秒,5秒钟都退出了系统

Start Threads Count,当前行的线程总数;设置10个线程数

Initial Delay,Sec,延时启动当前行的线程;设置0秒后初始化

Startup Time,Sec,启动当前行所有线程达峰值所需时间;设置30秒后达到峰值

Hold Load For,Sec,当前行线程达到峰值后的稳定加载时间;设置达到峰值后持续30秒

Shutdown Time,停止当前行所有线程所需时间;设置5秒内结束所有线程

 监听器的图就可以得知,35秒的时候,线程总数15个,持续运行1分钟,又花了10秒停止线程,因此总共耗时了1分43秒。

持续时间,系统达到这些负载后,能不能稳定运行,性能会不会下降;

但负载量还不确定的情况下,服务器能处理的负载量是多少,哪些负载不能处理? 

这里就有了按步骤增加负载,慢慢往上加压;

【步进负载】

想看系统的负载量是多少,最大负载多少,是否可以平稳运行?

每60秒增加15个线程数,持续45秒

 观察日志和监听器,就可以知道系统在哪个负载下面平稳运行,能承担多大的负载;

【波浪形测试负载】

春运,每次开放抢票时,有大量用户涌入,等到下次开放时,又有大量用户涌入,就像波浪一样,不断敲击服务器,考验服务器的性能;

配置说明:
第一个阶段,花10秒的时间,启动15个线程,持续运行5秒,用5秒的时间停止掉
第二个阶段,第一阶段的线程都停止后,再开始启动第二个阶段的线程,花10秒的时间再启动15个线程,再持续运行5秒,用5秒的时间停止掉
第三个阶段、第四个阶段、第五个阶段,与第二阶段一样

这样像波浪一样拍打服务器,观察服务器的性能,看系统是否能平稳运行。

场景四、bzm - Concurrency Thread Group

Target Concurrency:目标并发(线程数)
Ramp Up Time【Time Unit可设置分钟 或 秒】:启动时间;若设置 1 min,则目标线程在1 imn内全部启动
Ramp-Up Steps Count:阶梯次数;若设置 5 ,则目标线程在 1min 内分5次阶梯加压(启动线程);每次启动的线程数 = 目标线程数 / 阶梯次数 = 10 / 5 = 2
Hold Target Rate Time【Time Unit可设置分钟 或 秒】:持续负载运行时间;若设置 2 ,则启动完所有线程后,持续负载运行 1 min,然后再结束
Time Unit:时间单位(分钟 或 秒)
Thread Iterations Limit:线程迭代次数限制(循环次数);默认为空,理解成永远,如果运行时间到达Ramp Up Time + Hold Target Rate Time,则停止运行线程【不建议设置该值】
Log Threads Status into File:将线程状态记录到文件中(将线程启动和线程停止事件保存为日志文件);

注:Target Concurrency只是个期望值,实际不一定可以达到这个并发数,得看上面的配置【电脑性能、网络、内存、CPU等因素都会影响最终并发线程数】
Jmeter会根据Target Concurrency的值和当前处于活动状态的线程数来判断当前并发线程数是否达到了Target Concurrency;若没有,则会不断启动线程,尽力让并发线程数达到Target Concurrency的值

关注点:阶梯增压过程
看Concurrency Thread Group负载预览图每次阶梯增压都是瞬时增压的,但是实际测试结果可以看到它也是有一个过渡期,并不是瞬时增压

关注点:持续负载运行结束后,所有线程瞬时释放
最后可以看到,官方描述【所有线程都是瞬时释放的】,但实际释放并没有,而是阶梯减少
普通的线程组有三种状态:启动、运行、释放;而Concurrency Thread Group的线程可以理解成只有两种状态:启动、运行;因为线程都在极短的时间内就结束了

Concurrency Thread Group和Stepping Thread Group的区别【官方描述】

1.Stepping Thread Group提供,Concurrency Thread Group不提供设置启动延迟时间,阶梯增压过渡时间,阶梯释放过渡时间
2.Stepping Thread Group可以阶梯释放线程,而Concurrency Thread Group是瞬时释放
3.Stepping Thread Group设置了需要启动多少个线程就会严格执行,Concurrency Thread Group会尽力启动线程达到Target Concurrency值

场景五、bzm - Arrivals Thread Group

bzm - Arrivals Thread Group比bzm - Concurrency Thread Group 多了一项Concurrency Limit;

Concurrency Limit:最大并发数限制。以避免出现内存不足的问题。

设置描述:1分钟除以2次,等于每次加压持续30秒,50个用户除以2次,等于每次加压25个用户,达到50个用户后持续跑5分钟,最大并发数限制为5个。场景负载如下:

场景整个过程中,保持5个并发数跑完;

场景六:bzm - Free-Form Arrivals Thread Group

Free-Form Arrivals跟Arrivals Thread Group多了一项Concurrency Limit;

Concurrency Limit:最大并发数限制。以避免出现内存不足的问题。

设置描述:

第一个阶段,花30秒的时间,启动15个线程
第二个阶段,在第一阶段加压后,直接启动20个线程,持续1分钟的时间
第三个阶段,在第二阶段加压后,直接启动25个线程,持续3分钟的时间

整个线性负载过程中,最大并发数限制为5个,场景负载如下:

并发过程达到上限设定:5个,一直持续到结束时间

评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值