jmeter中线程数，Ramp-Up Period，循环次数之间

原文章https://blog.csdn.net/hsd412237463/article/details/49929173

image.png
刚接触jmeter时，对这三个参数只理解其字面意思 即：

线程数：并发数（可以想象成进游乐场的排队窗口个数）
Ramp-Up Period：准备时间（游乐场多个排队窗口从第一个到最后一个启用消耗的时间）
循环次数：每个线程执行次数（每个窗口有多少人排队）

可是对于这三个参数之间是如何相互关联，如何影响压测结果以及如何选择合适的组合是一脸懵逼的，只知道线程要从小压到大。。。

还有一些疑惑不明白：比如一次压测执行的时间与接口平响、吞吐量这三个参数是如何受 线程组中的【线程数、Ramp-Up Period、循环次数】影响

image.png

看了这篇文章后才对这些有了清晰的理解https://blog.csdn.net/hsd412237463/article/details/49929173

一、线程的发起

image.png

线程数n = 10
Ramp-Up Period t = 10
r = 1
以上图中参数为例，我们将发起10个线程，每个线程执行一次，在10秒内发起全部的线程（Ramp-Up Period=0时，同时发起所有线程）

• 那么每个线程发起的时间间隔为 n/t = 10/10 =1 每隔一秒发起一个，最后一个线程发起的时间为【t10 = t - n/t = 9】
  结果可以从jmeter的执行日志中验证

2020-11-04 22:44:22,068 INFO o.a.j.t.JMeterThread: Thread started: 线程组 1-1
2020-11-04 22:44:23,085 INFO o.a.j.t.JMeterThread: Thread started: 线程组 1-2
2020-11-04 22:44:24,088 INFO o.a.j.t.JMeterThread: Thread started: 线程组 1-3
2020-11-04 22:44:25,069 INFO o.a.j.t.JMeterThread: Thread started: 线程组 1-4
2020-11-04 22:44:26,067 INFO o.a.j.t.JMeterThread: Thread started: 线程组 1-5
2020-11-04 22:44:27,066 INFO o.a.j.t.JMeterThread: Thread started: 线程组 1-6
2020-11-04 22:44:28,065 INFO o.a.j.t.JMeterThread: Thread started: 线程组 1-7
2020-11-04 22:44:29,069 INFO o.a.j.t.JMeterThread: Thread started: 线程组 1-8
2020-11-04 22:44:30,067 INFO o.a.j.t.JMeterThread: Thread started: 线程组 1-9
2020-11-04 22:44:31,068 INFO o.a.j.t.JMeterThread: Thread started: 线程组 1-10

二、影响压测执行时间的因素

image.png

压测执行时间T = 9s
最后一个线程发起时间 t10 = t - n/t = 9
接口平均响应 p = 160ms = 0.16s

• 那么 T = t10 + p = 9.16s
  可以从执行日志中验证(结果为9.173s)，十分接近（实际有一定误差）

2020-11-04 22:44:22,068 INFO o.a.j.t.JMeterThread: Thread started: 线程组 1-1

2020-11-04 22:44:31,241 INFO o.a.j.t.JMeterThread: Thread is done: 线程组 1-10

吞吐量throughput = 线程数n * 循环次数r / 压测执行时间T 约等于 1.1
对于单个接口来说可以认为这次压测的结果为1.1QPS （每秒处理1.1个请求）

三、如何选择合适的参数搭配

根据以上实验结果我们可以获得以下结论：

线程数n = 10
Ramp-Up Period t = 10
r = 1
接口平均响应 p

最后一个线程发起时间 tn =  t - n/t
压测执行时间 T = tn + p

那么每次执行的QPS为
QPS_n = n * r / T =n * r / (tn + p) = n * r / ((t - n/t) + p) = n * r / ( t*t - n + p)
根据公式可以发现要想得到更高的QPS（最大值受实际被压系统等因素影响）

• 接口平均响应时间p 在一定情况下是不会变小的（调优使p变小）

结果就是需要使n * r 的值变大，这就是我们一般听到的逐渐加大线程数
还有一个就是减少 t的值，但如果t过小这会带来一些其他的问题：系统在瞬间承受较大的压力，容易把系统压垮，响应时间分布较大，不符合实际场景。

Ramp-Up Period t

• 我们如何选择合适的 t？
  从上面【线程的发起】我们可以得到在 t != 0 时，线程是逐个发起的，那么其中可能存在一个问题：

  
  image.png

当最后一个线程发起时，第一个线程早已结束，或者线程之间存在空隙(系统没有在处理请求)
那么，我们理想的情况应该是
在最后一个线程发起时，第一个线程处理完毕

同样以上面的数据为例

线程数n = 10
Ramp-Up Period t = 10
r = 1
接口平均响应 p = 0.16s

最后一个线程发起时间 tn =  t - n/t = 9
压测执行时间 T = tn + p = 9.16

要使最后一个线程发起时第9s第一个线程结束

image.png

第一个线程的请求数N
N = tn / p
可以得出N=56.25，也就是循环次数r > 56时，才能达到【最后一个线程发起时，第一个线程结束】

测试

取N=60
可以通过日志看到最后一个线程发起时，第一个线程即将结束（N+4使线程执行时间延长）

2020-11-04 23:54:17,998 INFO o.a.j.t.JMeterThread: Thread started: 线程组 1-1

2020-11-04 23:54:26,983 INFO o.a.j.t.JMeterThread: Thread started: 线程组 1-10

2020-11-04 23:54:33,901 INFO o.a.j.t.JMeterThread: Thread is done: 线程组 1-1

以下资料引用: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。 糟糕的测试计划通常会导致这些问题，这是因为在这样的测试计划里，取样器将不能充分地采集数据，可能因为测试计划执行时间太短并且线程会很快的运行结束。

把这次压测执行完

• 以上得出第二个QPS = 27.5

  
  image.png

• 线程数逐步加到60

  
  image.png

可以得到QPS=82

可以继续加压直到QPS不在上升（无异常或低于99.9%），可获得单前最大QPS
这个QPS与实际值有误差

• 受发压机性能影响（发起请求的速度）
• 网络（发压机发出请求 ---> 服务器收到请求）+ 实际响应时间 + （服务器发出请求 ---> 发压机收到请求）
  解决方案：
• 使用多台发压机
• 在服务器发压（或者局域网）

QPS是否有效？

如上得到QPS为82
但是我们也要注意到有部分请求的响应时间与平均值之间的误差

image.png

这里需要结合业务需要判断当前的响应时间是否超出预期
如果超出预期，则目前的QPS可以认为是无效的

这时需要检查代码内 各个方法的执行时间以及数据库压力
采取降低代码复杂度，优化数据查询等措施进行调优