这是我的测试计划线程属性的配置：
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）。我不知道循环计数是如何或是否影响这一点。
答案 0 :(得分：58)
Thread Group中的加速是JMeter开始线程总数所需的时间。在您的情况下，这意味着每隔0.1秒，新线程在10秒后开始提供100个正在运行的线程。这100个线程背靠背地执行测试迭代，因此在增加之后，100个线程在测试期间连续运行。
答案 1 :(得分：18)
加速期 - 所有请求启动的时间范围（以秒为单位）。 Number of Threads 输入中指定的所有主题都将在 Ramp-up period 内开始。
例如：
100个线程和100秒加速：每秒JMeter将启动 1个线程，直到所有线程在 100秒时启动>起来了。
100个主题和50秒加速每秒启动 2个主题。
100个主题和200秒加速：每 2秒， 1个主题启动。
现在，
示例或请求生成与线程生成的概念不同。在这种情况下，100个线程在10秒内启动。这里的关键因素是Throughput。 根据JMeter词汇表：
吞吐量计算为请求/时间单位。现在的时间是 从第一个样本的开始到最后一个样本的结束计算 样品。这包括样本之间的任何间隔，正如它所假设的那样 表示服务器上的负载。
公式为：吞吐量= （请求数量）/（总时间）。
此处执行的样本或请求数为 1050975 ，测试持续时间为 50820 秒。因此，这与吞吐量有关。 1050975 中的输出 50820s 请求表示整个测试中的平均吞吐量近似 20.5/s 。
要控制Throughput或Transactions per second，可以使用名为Constant Throughput Timer的非常方便的JMeter插件。
恒定吞吐量计时器引入变量暂停，计算到 保持总吞吐量（以每分钟样本数计）尽可能接近 可能给定的数字。当然，如果吞吐量会降低 服务器无法处理它，或者其他计时器或 耗时的测试元素阻止它。
答案 2 :(得分：12)
提升期告诉JMeter需要多长时间才能“提升”到完整的线程数。
@Little Chicken 理解1是正确的。
如果使用10个线程，并且加速时间为10秒，则JMeter将花费10秒钟来启动并运行所有10个线程。
每个线程将在上一个线程开始后1秒开始。
答案 3 :(得分：3)
加速期告诉JMeter需要多长时间才能“加速”到所选的全部线程数。如果使用10个线程，并且加速时间为100秒，则JMeter将花费100秒来使所有10个线程启动并运行。每个线程将在上一个线程开始后10（100/10）秒开始。如果有30个线程且120秒的上升周期，则每个后续线程将延迟4秒。
答案 4 :(得分：1)
理解1：是正确的 加速期告诉JMeter需要多长时间才能“加速”到所选的全部线程数。如果10 使用线程，并且加速时间为100秒，然后JMeter将花费100秒来获得全部10个 线程正在运行。每个线程将在上一个线程开始后10（100/10）秒开始。如果有 是30个线程，120秒的斜升时间，然后每个连续的线程将延迟4秒
答案 5 :(得分：0)
加速期间：用户将被绑定以开始交易的比率。
在jMeter中，如果您的加速时间为20，则有10个用户，则1个用户将每2秒开始执行该计划。
答案 6 :(得分：0)
此属性告诉JMeter在启动每个用户之间延迟多长时间。
例如，如果您输入5秒的加速期，JMeter将会 在5秒结束时完成所有用户的启动。因此，如果 我们有5个用户和5秒的Ramp-Up Period，然后延迟 起始用户将是1秒（5个用户/ 5秒=每个用户1个） 第二）。如果将值设置为0，则JMeter将立即启动 所有用户。
答案 7 :(得分：0)
例如