【转】关于JMeter线程组中线程数,Ramp-Up Period,循环次数之间的设置概念

时间:2023-12-25 23:00:49

关于JMeter线程组中线程数,Ramp-Up Period,循环次数之间的设置概念

【转】关于JMeter线程组中线程数,Ramp-Up Period,循环次数之间的设置概念

笔者是个刚刚踏入压力测试领域不到2个月的小菜,这里分享一下线程组中3个参数之间关系的个人见解,不喜请!喷!,望大家给出宝贵的想法。

假设:

线程数:n

Ramp-Up Period:T (有人称之为启动时间,有人说是准备时长,看个人喜好)

循环次数:a

若每个循环运行时间是 t

当时间到 S = (T- T/n)时,最后一个线程启动,若要使所有线程同时运作,则需要在最后一个线程启动的时候第一个线程仍未关闭,为达到这个要求,需满足 a·t > S及a > S/t

每一个个线程运行时间既是R = a·t(此处的a是大于S/t的某一值),则第一个线程在时间点为R 的时候停止,整个测试理论运行时间则是 :S + R = (1-1/n)·T + a·t

总结:

测试中变量是 线程数 n ,每个循环时间 t 是个实践值,循环次数 a 只是为了延长单个线程的运行时间,从而保证当最后一个线程启动时,所有线程都在运行中,达到压测效果。

以上是我个人的总结,额,什么?看不懂!其实笔者写完了也晕了,下面我们用确切的数值进行试验

我们设置线程数 n = 5,循环次数a = 1000,请求www.google.com,得到聚合报告如图:

【转】关于JMeter线程组中线程数,Ramp-Up Period,循环次数之间的设置概念

图中得到谷歌首页的平均请求时间大约为t = 0.2秒

这里,我们为了方便分析,将Ramp-Up Period 设置为T = 10秒(实际合理的时间后面会说明)

依然是n = 5,得到 S = (T- T/n) = 8 ,也就是说,从第一个线程启动到第8秒的时候,最后一个线程开始启动,若需要在最后一个线程启动的时候第一个线程仍未关闭,则需要满足 a·t > S ,已知S = 8,t = 0.2,得到 a > 40 。

OK,既然循环次数要大于40,我们不妨把循环设置成100,那么单个线程运行时间就是R = a·t = 20秒,也就是说第一个线程会在第20秒的时候停止,整个测试的理论运行时间为 S + R = (1-1/n)·T + a·t = 28秒

我们用一张图来直观的看看每个线程的运行情况

【转】关于JMeter线程组中线程数,Ramp-Up Period,循环次数之间的设置概念

从图中可以得到从第8秒开始,到第20秒,5个线程同时在运行中,此时才是真正的模拟5个用户同时并发

说了这么多,我们的目的到底是什么?无非是如何设置线程数,Ramp-Up Period以及循环次数。线程数我就不多说了,看各个项目的测试需求,而刚刚我说了这么多,实质上只是介绍了一些概念和如何合理的设置循环次数,至于Ramp-Up Period如何合理这是,请看下面大神的分析。

作为菜鸟,笔者以菜鸟的文笔和想法污染的大家的大脑,请见谅,还是那句话,不喜请!喷!

以下资料引用:http://www.knowsky.com/367353.html

每个线程均独立运行测试计划。因此, 线程组常用来模拟并发用户访问。假如客户机没有足够的能力来模拟较重的负载,可以使用Jmeter的分布式测试功能来通过一个Jmeter控制台来远程控制多个Jmeter引擎完成测试。

  参数 ramp-up period 用于告知JMeter 要在多长时间内建立全部的线程。默认值是0。假如未指定ramp-up period ,也就是说ramp-up period 为零, JMeter 将立即建立所有线程,假设ramp-up period 设置成T 秒, 全部线程数设置成N个, JMeter 将每隔T/N秒建立一个线程。

  线程组的大部分参数是不言自明的,只有ramp-up period有些难以理解, 因为如何设置适当的值并不轻易。 首先,假如要使用大量线程的话,ramp-up period 一般不要设置成零。 因为假如设置成零,Jmeter将会在测试的开始就建立全部线程并立即发送访问请求, 这样一来就很轻易使服务器饱和,更重要的是会隐性地增加了负载,这就意味着服务器将可能过载,不是因为平均访问率高而是因为所有线程的第一次并发访问而引起的不正常的初始访问峰值,可以通过Jmeter的聚合报告监听器看到这种现象。 
这种异常不是我们需要的,因此,确定一个合理的ramp-up period 的规则就是让初始点击率接*均点击率。当然,也许需要运行一些测试来确定合理访问量。

  基于同样的原因,过大的ramp-up period 也是不恰当的,因为将会降低访问峰值的负载,换句话说,在一些线程还未启动时,初期启动的部分线程可能已经结束了。

  那么,如何检验ramp-up period I太小了或者太大了呢?首先,推测一下平均点击率并用总线程除点击率来计算初始的ramp-up period。 例如,假设线程数为100, 估计的点击率为每秒10次, 那么估计的理想ramp-up period 就是 100/10 = 10 秒。 那么,应怎样来提出一个合理的估算点击率呢?没有什么好办法,必须通过运行一次测试脚本来获得。

  其次, 在测试计划(test plan)中增加一个聚合报告监听器,如图2所示,其中包含了所有独立的访问请求(一个samplers)的平均点击率。 第一次取样的点击率(如http请求)与ramp-up period 和线程数量密切相关。通过调整ramp-up period 可以使首次取样的点击率接*均取样的点击率。

第三, 查验一下Jmeter日志(文件位置:JMeter_Home_Directory/bin) 的最后一个线程开始时第一个线程是否真正结束了,二者的时间差是否正常。

  总之,是否能确定一个适当的ramp-up time 取决于以下两条规则: 
  ·第一个取样器的点击率(hit rate)是否接近其他取样器的平均值,从而能否避免ramp-up period 过小。
  ·在最后一个线程启动时,第一个线程是否在真正结束了,最好二者的时间要尽可能的长,以避免ramp-up period过大。

  有时,这两条规则的结论会互相冲突。 这就意味着无法找到同时满足两条规则的合适的ramp-up period。 糟糕的测试计划通常会导致这些问题,这是因为在这样的测试计划里,取样器将不能充分地采集数据,可能因为测试计划执行时间太短并且线程会很快的运行结束。

---------------------
作者:hsd412237463
来源:CSDN
原文:https://blog.csdn.net/hsd412237463/article/details/49929173
版权声明:本文为博主原创文章,转载请附上博文链接!