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

Question

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

实验信息

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

Locust.io

setup：使用 pyzmq，并将每个 vCPU 内核设置为从属。单个 POST 请求设置，请求正文 ~ 20 字节，响应正文 ~ 25 字节。请求失败率：

变量：连续请求之间的时间设置为 450 毫秒（最小：100 毫秒，最大：1000 毫秒），孵化率以舒适的每秒 30 次为单位，RPS 由不同的#_users 测量em>。

RPS 遵循对多达 1000 个用户的预测等式。在此之后增加 #_users 会导致收益递减，上限约为 1200 个用户。 #_users 这里不是自变量，更改等待时间 也会影响 RPS。但是，将实验设置更改为 32 核实例（c3.8x 实例）或 56 核（在分布式设置中）根本不会影响 RPS。

所以说真的，控制 RPS 的方法是什么？我在这里有什么明显的遗漏吗？

Answer 1

（这里是 Locust 的作者之一）

首先，为什么要控制 RPS？ Locust 背后的核心思想之一是描述用户行为并让它产生负载（在您的情况下是请求）。 Locust 旨在回答的问题是：我的应用程序可以支持多少并发用户？

我知道追求某个 RPS 号码是很诱人的，有时我也会通过争取任意 RPS 号码来“作弊”。

但要回答您的问题，您确定您的 Locusts 不会陷入死锁吗？例如，他们完成了一定数量的请求，然后因为没有其他任务要执行而变得空闲？不看测试代码很难判断发生了什么。

建议将分布式模式用于较大的生产设置，并且我运行的大多数实际负载测试都是在多个但较小的实例上进行的。但是，如果您没有最大限度地使用 CPU，这无关紧要。您确定没有使单个 CPU 内核饱和吗？不确定您运行的是什么操作系统，但如果是 Linux，您的负载值是多少？