目录
性能测试Jmeter,常用的场景
场景一:Thread Group
场景二、jp@gc - Stepping Thread Group
场景三、jp@gc - Ultimate 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秒的时间停止掉
第三个阶段、第四个阶段、第五个阶段,与第二阶段一样
这样像波浪一样拍打服务器,观察服务器的性能,看系统是否能平稳运行。