实现目标 JMeter 吞吐量值的限制

Limitations in achieving a target JMeter throughput value

我想了解在运行时实现的实际 JMeter 吞吐量行为。

场景 - 我正在使用常量吞吐量计时器和 beanshell 脚本在运行时增加 JMeter 吞吐量，如此处所述 - https://www.blazemeter.com/blog/how-to-change-jmeters-load-during-runtime。

测试计划 - 与上述 CTT 一起，配置了具有固定#threads 和无限循环迭代的简单线程组。使用 GET 调用的 HTTP 取样器。测试计划中没有添加其他计时器或插件。

当我在运行时不断增加 JMeter 的目标吞吐量时，我注意到实际实现的吞吐量值主要受 2 个因素的限制 -

  1. 我的线程组中的线程。
  2. 目标应用的性能瓶颈

我对这两个限制有疑问 -

  1. 一旦使用当前线程组中的所有线程达到最高吞吐量（假设目标应用程序还没有错误），是否有办法在此时动态增加#threads运行时实现更高的 JMeter 吞吐量？

  2. 现在，当我继续增加 JMeter 吞吐量时，由于目标应用程序的错误，它无法进一步增加。 JMeter 如何识别我的目标应用程序的性能瓶颈并对其做出反应？它是否会增加任何延迟或终止线程或应用任何此类机制来将其吞吐量降低到目标应用程序可以承受的最大值？

  3. 继续第 2 点，如果 JMeter 通过任何方法识别性能瓶颈并对其做出反应，控制其吞吐量的因素（如错误率、响应延迟等）是什么以保持它在目标应用程序的最大限制内？这些因素是否可配置或可扩展？

  1. 您可以对线程组中的线程数玩同样的把戏，只需使用 __P() function and you will be able to manipulate it using Beanshell server. Another option is using a JSR223 Test Element and Groovy language 定义它以添加新线程 where/when 所需的就像:

    ctx.getThreadGroup().addNewThread(0, ctx.getEngine())

  2. JMeter 不“识别”任何东西，它只是尝试尽可能快地执行采样器，每秒请求数取决于两个因素：

    • 您的应用程序需要能够足够快地响应
    • JMeter本身需要能够足够快地发送请求，即你需要遵循JMeter Best Practices

    没有检测被测应用程序行为的“机制”，最接近的解决方案是Auto Stop Listener

  3. 见第2点