【问题标题】:Concurrency Thread Group and Throughput shaping timer并发线程组和吞吐量整形计时器
【发布时间】:2021-07-21 14:27:24
【问题描述】:

我想为我正在处理的应用程序模拟 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 的吞吐量,还是我遗漏了什么?

第二季度。我如何提前计算需要在 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 - 并发线程组-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 可以使用的用户可用?

【问题讨论】:

    标签: jmeter


    【解决方案1】:

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

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

    • 第二季度。争取有史以来最长的响应时间,根据 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 页面上提供的最新稳定版本

    【讨论】:

      猜你喜欢
      • 1970-01-01
      • 1970-01-01
      • 1970-01-01
      • 1970-01-01
      • 2022-01-25
      • 1970-01-01
      • 1970-01-01
      • 1970-01-01
      • 1970-01-01
      相关资源
      最近更新 更多