JMeter 线程组每秒未达到指定事务

问题描述

我在 JMeter 5.4.1 中遇到了一个问题,我的线程组没有达到每秒指定的事务数。

我在一个并行运行的 JMeter 测试中有两个线程组。每个线程组都在进行一次 API 调用。第一个线程组分配了 300 个线程,并有一个恒定吞吐量计时器,目标吞吐量为每分钟 45,000 个样本,最终达到每秒 750 个事务。第二个线程组分配了 100 个线程,并有一个恒定吞吐量计时器,目标吞吐量为每分钟 9,000 个样本,最终达到每秒 150 个事务。

运行多次测试后,两个线程组都无法达到其目标吞吐量。第一个线程组每秒命中大约 300 个事务,第二个线程组每秒命中大约 100 个事务。第一个线程组的平均响应时间为 5 毫秒,第二个线程组的平均响应时间为 8 毫秒。这让我相信测试时的服务保持良好,但 JMeter 机器不是。

奇怪的是,在单个 JMeter 实例上并行运行这些线程组会导致每秒事务数减少。我们进行了一个实验,将两个线程组拆分为两个不同的 JMeter 实例,并在同一台机器上同时运行它们。这使我们能够达到正确的交易/秒。这让我相信机器可以跟上,但是当它在一个 JMeter 实例中运行这两个线程时,JMeter 有一些奇怪的地方。关于为什么会这样以及如何解决它的任何线索?

解决方法

  1. Constant Throughput Timer 只能暂停 JMeter 的线程以限制吞吐量到所需的值,如果当前数量是,它不会启动任何额外的线程不足以进行所需的负载。能够做到这一点的选项是 Concurrency Thread GroupThroughput Shaping Timer 组合(请在尝试之前阅读答案直到最后)

  2. 您的应用程序需要足够快的响应,即如果您尝试使用 300 个线程实现每秒 750 个请求,则最大响应时间需要小于或等于 400 毫秒,如果需要更长的时间 - 吞吐量将按比例降低。

  3. JMeter 需要能够足够快地发送请求,您不能在糟糕的笔记本电脑上运行它并期望它能够针对分布式自动扩展集群成功DoS attack,因此: