Gatling（和JMeter）努力维持每秒请求数（RPS）？

Question

我正在加载测试API。我们有一个问题 - 我们的响应时间太长，有时接近一分钟。我们想要在不到一秒的范围内。但这是重点。

当我使用负载测试工具（如Gatling）时，发送的RPS似乎停止了。正如您在附图中看到的那样，最初的15秒是20RPS，突然几乎没有RPS。我怎样才能保持恒定的RPS？可能它与响应时间很短有关，但如果我不关心响应时间呢？我只想让RPS保持不变。

我对JMeter的初步测试也表现出类似的行为。

Answer 1

你使用什么注射策略？场景如何看？每个用户是在一个循环中发出一个请求，一个请求链还是上面的任何一个？

假设您要测试单个端点，每秒获得常量请求的最佳方法（不是您已经知道的常量响应）是使用执行单个请求和策略的方案，每秒注入固定数量的用户fe：

setUp(
  scn.inject(constantUsersPerSec(25) during(15 minute))
)

如果您的用户执行了多于1个请求，则可以选择限制请求，但您需要记住它只会降低权限，因此您需要确保活动用户每秒发出足够的请求以达到该限制：

setUp(scn.inject(
  constantUsersPerSec(10) during(15 minutes)
).throttle(
  jumpToRps(25), holdFor(15 minutes)
))

所以，如果fe。单个用户发出5个请求甚至可以达到50个req​​ / s，但它会被限制为25个。但是你必须记住每秒都会添加新用户，所以如果需要更多时间来完成1个用户，那么活跃用户数就会增加。此外，如果响应时间很长，那么活动用户可能无法产生足够的req / s，因为他们的大部分时间都在等待响应。

Answer 2

在JMeter中，您可以通过在测试计划级别使用Constant Throughput Timer来实现这一目标。

常量吞吐量计时器允许您维护服务器的吞吐量（请求/秒）。常量吞吐量计时器只能暂停JMeter线程，以减慢它们的速度以达到目标吞吐量。此外，它仅在一定程度上工作，因此您需要正确计算加速期并让您的测试运行足够长。

让我们看一下这个简短的想法：

要实现目标吞吐量，您需要在测试计划中拥有足够数量的线程。

要计算此测试所需的线程数，可以使用以下公式：

RPS *最大响应时间以秒为单位

在您的情况下，如果您想要20 RPS并且您的最大响应时间是60秒，则您的测试计划中至少需要1200（20*60=1200）线程。

由于恒定吞吐量计时器在一定程度上工作，要实现20 RPS，您必须将“目标吞吐量”值配置为1200/min，并将“基于值计算吞吐量”值配置为“All active threads”。

恒定吞吐量计时器配置：

现在，如果您的测试计划中有多个请求（即4 requests），那么1200 requests/min将在4 samplers中分发。这意味着你将获得每个采样器的5RPS。

现在，对于Thread Group配置，正如您在“All active threads”的常量吞吐量计时器中提到的“基于计算吞吐量”值，因此需要在服务器上启动所有1200线程以实现20 RPS。使用Ramp-Up Period配置来控制这些线程的启动。

Ramp-Up Period是所有线程到达测试的应用程序服务器的时间。因此，如果您使用60 seconds，那么启动所有1200 threads需要60秒。在60 seconds中将有1200个线程处于活动状态。

您还需要相应地设置测试持续时间。说，你想保持20 RPS为5 minutes。在这种情况下，您必须为7 mins设置测试持续时间（2分钟额外用于：启动1200个线程开始1分钟，这是加速时间，1200线程减速时间持续1分钟）。如果您使用Forever，请不要忘记检查Thread Group的循环计数。

针对上述场景的线程组配置：

如果您对默认的Ultimate Thread Group配置感到困惑，您还可以使用另一个方便的JMeter插件，即Thread Group。您可以使用JMeter Plugins Manager下载JMeter插件。

以下是针对上述场景的Ultimate Thread Group Config：

现在，在测试结束后，您可以使用5 minutes以及Hits Per Second Listener检查那些Active Threads Over Time Listener结果，其中所有1200个线程都处于活动状态。

不要使用JMeter GUI进行负载测试，请使用非GUI模式。此外，如果您在尝试实现某些目标RPS时测试计划中有任何断言，请删除断言。