JMeter理解斜坡上升

Question

这是我的测试计划线程属性的配置：

Number of Threads (users): 100
Ramp-up Period (in seconds): 10
Loop Count : Forever
Delay thread creation until needed: No
Scheduler: No

我用14小时7分钟（约50820秒）的总时间进行了一夜测试。加载jtl文件后，汇总报告中显示的样本数为1050975。我试着计算，但我不明白它是怎么得出这么多样本的。

如果Ramp up Period是JMeter创建每次迭代的线程数所花费的时间，如果测试的持续时间是50820秒，那么我应该只有508200个样本（50820/10*100）。我不知道循环计数如何或是否会影响这一点。

Answer 1

爬升周期告诉JMeter“爬升”到完整线程数需要多长时间。

@小鸡理解1是正确的。

如果使用了10个线程，并且升级周期为10秒，那么JMeter将需要10秒来启动和运行所有10个线程。

每个线程将在上一个线程开始后1秒开始。

Answer 2

爬升周期—所有请求开始的时间范围（以秒为单位）。在线程数输入中指定的所有线程将在爬升期内启动。

例如：

100个线程和100秒加速：每秒JMeter将启动一个线程，直到100秒结束时所有线程都启动。

100个线程和50秒爬升：每秒启动2个线程。

100个线程和200秒爬升：每2秒启动一个线程。

现在

示例或请求生成与线程生成是不同的概念。在你的例子中，100个线程在10秒内启动。这里的关键因素是吞吐量。根据JMeter词汇表：

吞吐量按请求/时间单位计算。计算从第一个样本开始到最后一个样本结束的时间。这包括样本之间的任何间隔，因为它应该表示服务器上的负载。

公式为：吞吐量=（请求数）/（总时间）。

此处执行的样本或请求数为1050975，测试持续时间为50820秒。这与吞吐量有关。50820s中的输出1050975请求意味着整个测试的平均吞吐量约为20.5/s。

要控制吞吐量或每秒事务数，有非常方便的JMeter插件，称为常量吞吐量计时器。

恒定吞吐量计时器引入了可变的暂停，通过计算使总吞吐量（以每分钟样本数为单位）尽可能接近给定的数字。当然，如果服务器无法处理吞吐量，或者如果其他计时器或耗时的测试元素阻止吞吐量，则吞吐量会降低。

Answer 3

线程组中的爬升是JMeter启动线程总数所需的时间。在您的情况下，这意味着每0.1秒一个新线程在10秒后开始提供100个运行线程。这100个线程背靠背地执行您的测试迭代，因此在爬升之后，100个线程在测试期间持续运行。