Locust.io：控制每秒请求参数

Question

我一直在尝试使用Locust.io在EC2计算优化实例上进行API服务器的负载测试。它提供了一个易于配置的选项，用于设置连续请求等待时间和并发用户数量。理论上，rps = wait time X #_users。然而，在测试时，这个规则在非常低的#_users阈值下（在我的实验中约为1200个用户）会失效。变量hatch_rate、#_of_slaves（包括在分布式测试设置中）对rps几乎没有影响。

实验信息：

测试是在一个C3.4x AWS EC2计算节点（AMI映像）上进行的，具有16个vCPU、通用SSD和30GB RAM。在测试期间，CPU利用率峰值达到60%（取决于孵化速率-控制并发进程生成），平均保持在30%以下。

Locust.io：

设置：使用pyzmq，并将每个vCPU核心设置为从属。单个POST请求设置，请求体~20字节，响应体~25字节。请求失败率：<1%，平均响应时间为6ms。

变量：连续请求之间的时间设置为450ms（最小值：100ms，最大值：1000ms），孵化速率为每秒30个，并通过变化#_users来测量RPS。

RPS遵循预测的方程，最多可达到1000个用户。增加#_users后，收益递减，在大约1200个用户时达到峰值。在这里，#_users不是独立变量，改变wait time也会影响RPS。然而，将实验设置更改为32个核心实例（c3.8x实例）或56个核心（在分布式设置中）并不会对RPS产生影响。

那么，控制RPS的方法是什么？我是否漏掉了一些明显的东西？

- siddharthlatest

Answer 1

（这是Locust的作者之一）

首先，为什么要控制请求每秒（RPS）？Locust 的核心思想之一是描述用户行为并让其生成负载（在您的情况下是请求）。Locust 设计的问题是：我的应用程序支持多少并发用户？

我知道追求特定的 RPS 数字很诱人，有时候我也会“作弊”，努力达到任意的 RPS 数字。

但是回答您的问题，您确定您的 Locust 没有陷入死锁状态吗？也就是说，它们完成了一定数量的请求，然后变得空闲，因为没有其他任务需要执行？如果没有看到测试代码，很难确定发生了什么。

对于较大的生产设置和大多数我进行过的真实世界负载测试，建议使用分布式模式和多个较小的实例。但是，如果未达到 CPU 的最大利用率，则无所谓。您确定没有饱和单个CPU 核心吗？不确定您正在运行什么操作系统，如果是Linux，则 load 值是多少？

- cgbystrom

---

我追求RPS的原因之一是因为我知道用户（例如2个），但对于Locust而言，2个用户会产生110+ RPS的请求，但在现实世界中，这2个用户每秒只能发出1-2个请求？这有助于确定基于用户的负载吗？ - ashutosh

Answer 2

虽然没有直接控制每秒请求数的方法，但你可以在wait_time中尝试使用constant_pacing和constant_throughput选项。从文档中可以看到例子：https://docs.locust.io/en/stable/api.html#locust.wait_time.constant_throughput。在下面的示例中，无论任务执行时间如何，该任务将始终每秒执行一次。

class MyUser(User):
    wait_time = constant_throughput(1)

constant_pacing是其反义词。

因此，如果您使用100个并发用户运行测试，测试将以100rps的速度运行（假设每个请求在第一次执行时都少于1秒）。

- Ritesh