JMter定时器和聚合报告
about
在默认情况下,jmeter发送每个请求的间隔极短,如果线程数足够大,瞬间就会将服务器压死。
在实际的业务过程中,请求之间是有一定时间的停顿的,比如登录网站时输入用户名和密码需要时间(用户会确认下输入的对不对),所以在请求之间设置合理的延时是必须的,也更接近用户的真实业务情况。
在jmeter中,定时器组件提供了系列不同类型的延时控制。合理使用定时器组件,能让你的性能测试更接近真实,更能挖掘出系统的瓶颈和评估系统的性能指标。
基本规则:在每个采样器(sampler)之前去执行,也就是定时器的作用域:
- 定时器是在每个采样器(sampler)之前执行的,而不是之后(无论定时器位置在采样器(sampler)之前还是下面)。
- 当执行一个采样器(sampler)之前时,所有当前作用域内的定时器都会被执行。
- 如果希望定时器仅应用于其中一个采样器(sampler),则把定时器作为子节点加入。
截止到目前,jmeter共提供了如下几种定时器,以适应更多的场景:
我们来看看常用的定时器的用法。
固定定时器
固定定时器,应用场景,登录,比如用户在输入完密码之后,会思考一下用户密码是否输入有误,然后再点击登录,那么这个固定定时器,就可以等2秒再去执行,那也因此有些问题,这个固定的时间相对比较死板。
在线程组内新建一个"HTTP请求"取样器,并为该取样器添加一个"固定定时器":
"固定定时器"的配置:
结果,没啥好看的:
同步定时器
场景应用:0点秒杀
"同步定时器",jmeter集合点是通过这个定时器来实现的,也就是人为并发。
PS:集合点用于同步虚拟用户恰好在某一时刻执行任务,确保用户更准确、集中的进行某个指定操作,达到更理想的负载模拟效果,更有针对性地对某个可能存在性能问题的模糊或子系统施压,以便找到性能瓶颈。
简单来说,集合点的概念,相当于我们10个人约好明天上午9点一起去逛街,那么到明天上午九点,会有如下几种情况:
- 10个人在9点之前就凑齐了,走吗?不走!要等9点再走!
- 9点了,10个人才到了8个,那还等剩下的两个人吗?可以选择等,如果永远凑不够10个,就一直等;还有一种情况就是,不等剩下的两个人了,直接到点就走,有几个人走几个人。
"同步定时器"通过不同的参数也能完成不同的场景,所以,它在做性能测试的时候,模拟的更准确。
首先,在线程组内添加一个"HTTP请求"取样器:
再为"HTTP请求"取样器添加一个"同步定时器":
接下来,我们来研究同步定时器各个参数组合情况,都有哪些不同的结果产生。
"同步定时器"的模拟用户组的数量参数,有以下几种情况:
-
等待所有的虚拟用户(线程)后,一次性发送所有的请求,示例:
- 线程组的线程数:5;
- 同步定时器的模拟用户组的数量:10;
- 同步定时器的超时时间以毫秒为单位:0;
- 结果是,jmeter会一直等凑够10个用户,但很明显,因为线程数为5,它永远也凑不够10个用户,而且也没设置超时时间,所以,jmeter就一直在等在凑够10个用户.....
-
如果设置为0,等同于设置为线程组中线程数的值,示例:
- 线程组的线程数:5;
- 同步定时器的模拟用户组的数量:0;
- 同步定时器的超时时间以毫秒为单位:1000;
- 结果是,如果在规定的超时时间内,凑够了5个用户,然后会一次性的发送5个请求;如果在规定的超时时间内,没有凑够5个用户,比如只凑够了3个,那么当超时时间结束后,会发送3个请求;如果没有设置超时时间,jmeter会在1000毫秒内发送5个请求。
-
如果设置的值不大于它所在线程组的线程数,jmeter会轮询的在超时时间结束发送指定的用户数,示例:
- 线程组的线程数:5;
- 同步定时器的模拟用户组的数量:4;
- 同步定时器的超时时间以毫秒为单位:2000;
- 结果是,如果在没达到超时时间时,哪怕jmeter凑够了4个用户,它也不发送请求,而是要等超时时间结束再一次性的发送所有的请求;问题来了,我们线程数时5个,此时发送了4个请求,还剩下1个用户每发送呢?怎么办?jmeter会在下一次超时时间结束在发送剩下的1个请求;如果线程数还没使用完,就继续在下一次轮询发送,你可以将线程数设置5,同步定时器的模拟用户数设置为2,超时为2000毫秒,再运行会发现,每2000毫秒发送2个用户,最后一轮会发送1个用户。
除了上述的几种情况之外,"同步定时器"的作用域也要引起你的注意:
- 如果它位于线程组内,跟其他请求同级,则所有的请求都会受此影响。
- 如果它位于指定的请求内,做只作用于该请求,不影响线程组内的其他请求。
聚合报告
聚合报告中各参数的分析。 lable:线程组的名称 Samples(样本):一共发出去多少个请求 Average(平均值):平均响应时间(ms) Medium(中位数):中位数响应时间,50%请求响应的时间(ms) 90%line:90%的请求响应不会超过该时间(ms) 95%line:95%的请求响应不会超过该时间(ms) 99%line:99%的请求响应不会超过该时间(ms) Min(最小值):最小响应时间(ms) Max(最大值):最大响应时间(ms) Error%(异常率):错误的请求数量 Throughput(吞吐量):默认情况下表示每秒完成的请求数 Received KB/sec:每秒接收数据量 Sent KB/sec:每秒发送数据量
线程组