加特林（和JMeter）努力维持每秒请求数（RPS）？

Question

我正在对API进行负载测试。我们遇到了问题-我们的响应时间过长，有时接近一分钟。我们希望在不到一秒的范围内。但这不是重点。

当我使用诸如Gatling之类的负载测试工具时，发送的RPS似乎停止了。如您在附图中所见，最初有15秒的20RPS，突然之间几乎没有RPS。如何保持恒定的RPS？可能与响应时间短有关，但是如果我不在乎响应时间怎么办？我只想要RPS不变。

我对JMeter的初步测试也显示出类似的行为。

Answer 1

您正在使用哪种注射策略？场景看起来如何？每个用户是否在一个循环中发出一个请求，一个请求链或以上任何内容？

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

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

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

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

所以这里是fe。单用户发出5个请求，您甚至可以达到50个请求/秒，但将被限制为25个。但是您必须记住，每秒将添加新用户，因此，如果花费更多时间来完成1个用户，则活动用户的数量将增加。同样，如果响应时间很高，则活动用户可能无法产生足够的请求/秒，因为他们的大部分时间都在等待响应。

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”的“恒定吞吐量计时器”中的“基于”计算吞吐量值，因此您所有{需要在服务器上启动{1}}个线程才能实现该1200。使用加速期配置来控制这些线程的启动。

加速期是所有线程到达测试的应用程序服务器上的时间。因此，如果您使用20 RPS，则将需要60秒才能启动所有60 seconds。 1200 threads中将有1200个线程处于活动状态。

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

用于上述情况的线程组配置：

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

以下是上述情况的最终线程组配置：

现在，在测试完成之后，您可以使用Hits Per Second Listener和Active Threads Over Time Listener来检查所有1200个线程都处于活动状态的Forever结果。

请勿使用JMeter GUI进行负载测试，请使用非GUI模式。另外，如果要达到目标RPS，请删除测试计划中的任何断言。