并发线程组和吞吐量整形定时器

Question

我想为我正在处理的应用程序模拟 100 rps。我计划使用并发线程组和吞吐量整形计时器。我创建了一个示例示例来测试它是如何工作的。下面是我的脚本

我已将此作为下一行添加到 log4j2.xml 文件中：

<Logger name="kg.apc.jmeter.timers.VariableThroughputTimer" level="debug" /> 

jmeter.log 有以下日志

2021-07-21 14:11:22,402 INFO c.b.j.c.VirtualUserController: Need to decrease concurrency, thread is done: bzm - Concurrency Thread Group-ThreadStarter 1-217
2021-07-21 14:11:22,402 INFO o.a.j.t.JMeterThread: Thread is done: bzm - Concurrency Thread Group-ThreadStarter 1-217
2021-07-21 14:11:22,402 INFO o.a.j.t.JMeterThread: Thread finished: bzm - Concurrency Thread Group-ThreadStarter 1-217
2021-07-21 14:11:22,407 DEBUG k.a.j.t.VariableThroughputTimer: Calculating 407 380.0 38
2021-07-21 14:11:22,427 INFO c.b.j.c.VirtualUserController: Need to decrease concurrency, thread is done: bzm - Concurrency Thread Group-ThreadStarter 1-218
2021-07-21 14:11:22,427 INFO o.a.j.t.JMeterThread: Thread is done: bzm - Concurrency Thread Group-ThreadStarter 1-218
2021-07-21 14:11:22,427 INFO o.a.j.t.JMeterThread: Thread finished: bzm - Concurrency Thread Group-ThreadStarter 1-218
........
........
2021-07-21 14:11:23,007 DEBUG k.a.j.t.VariableThroughputTimer: Second changed 60.0 , waiting: 0, samples sent 94, current rps: 100.0 rps
2021-07-21 14:11:23,007 WARN k.a.j.t.VariableThroughputTimer: No free threads available in current Thread Group bzm - Concurrency Thread Group, made 94 samples/s for expected rps 100.0 samples/s, increase your number of threads
2021-07-21 14:11:23,007 DEBUG k.a.j.t.VariableThroughputTimer: Calculating 7 0.0 0

我的问题是

第一季度。我是否正确配置了测试以模拟 100 rps 的吞吐量，还是我遗漏了什么？

第 2 季度。如何提前计算需要在 Target Concurrency 中添加多少用户？如果我使用公式

(rps * Maximum response time) / 1000

这里，我是否需要将所有采样器的最大响应时间从 1 添加到 6？或者怎么做？

第三季度。我们如何计算吞吐量？（参考具有聚合报告的第三张图片），

总吞吐量 = 采样器 1 到 6 的吞吐量，即 = (15.8 + 15.8 + 15.8 + 15.7 + 15.6 + 15.6) = 94.3 rps。我的计算是否正确？

第四季度。在jmeter.log中，它说“需要减少并发，线程完成：bzm - Concurrency Thread Group-ThreadStarter 1-217”。

这是否意味着模拟 100 rps 所需的线程（用户）数量更多，因此 jmeter 需要减少线程（用户）？

然后再次在日志中说，“当前线程组中没有可用的空闲线程 bzm - 并发线程组，为预期的 rps 100.0 样本/秒制作了 94 个样本/秒，增加您的线程数量”

是要求我（用户）增加线程还是只是 jmeter 在自言自语？ Jmeter 已经有 150 个线程可以使用。实际上，我从 50 开始，然后我也收到了增加线程数的消息，然后我将线程增加到 100，得到了相同的消息，最后我将其增加到 150，但仍然在日志中收到该消息？

如上图所示，在第 51 秒，jmeter 仅使用了 150 个线程（用户）中的 29 个。这意味着它还有 121 个线程可以使用。此外，我观察到当我启动脚本时，立即有 150 个线程正在使用中，但随后它们开始迅速减少和增加。然而，在 60 秒的运行期间，它们从未达到 150（150 个线程仅在开始时使用，几分之一秒后就减少了！）

那为什么日志中的消息会增加用户？事实上，有哪些用户可以使用 jmeter ？

Answer 1

你只是忘了问“Q5”：生命、宇宙和一切的终极问题

• 第一季度。我们不知道，这取决于应用程序的响应时间，您的 150 个线程可能足以也可能不足以进行每秒 100 个请求的负载

• Q2。争取有史以来最长的响应时间，根据 JMeter 线程模型，每个线程在开始下一个请求之前等待前一个请求完成，因此整个 6 个采样器序列将以最慢的一个的速度运行。

• 第三季度。吞吐量整形计时器尝试达到并维持其 scope 中所有采样器的定义吞吐量，因此如果范围内有 6 个请求，单个请求的吞吐量将为 100 / 6

• 第四季度。 Need to decrease concurrency - 计时器“自言自语”，通知它运行得太快，因此需要关闭几个线程以减慢请求速率。 increase your number of threads 是给你的，但我不认为它适用于你的情况，如果你运行真正的测试并且会在日志中看到大量这样的消息，这将表明当前数量不足以达到目标吞吐量

• 不要在 GUI 模式下运行您的测试，它仅用于测试开发和调试，执行时您must be using command-line non-GUI mode

• According to JMeter Best Practices you should always be using the latest version of JMeter 所以考虑升级到 JMeter 5.4.1 或 JMeter Downloads 页上提供的任何最新稳定版本