amazon-web-services - Locust.io : Controlling the request per second parameter

Question

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

Experiment info

The test has been done on a C3.4x AWS EC2 compute node (AMI image) with 16 vCPUs, with General SSD and 30GB RAM. During the test, CPU utilization peaked at 60% max (depends on the hatch rate - which controls the concurrent processes spawned), on an average staying under 30%.

Locust.io

setup: uses pyzmq, and setup with each vCPU core as a slave. Single POST request setup with request body ~ 20 bytes, and response body ~ 25 bytes. Request failure rate: < 1%, with mean response time being 6ms.

variables: Time between consecutive requests set to 450ms (min:100ms and max: 1000ms), hatch rate at a comfy 30 per sec, and RPS measured by varying #_users.

RPS 遵循为多达 1000 个用户预测的等式。之后增加#_users 的 yield 递减，上限达到大约 1200 名用户。 #_users 这里不是自变量，改变等待时间也会影响 RPS。但是，将实验设置更改为 32 核实例(c3.8x 实例)或 56 核(在分布式设置中)根本不会影响 RPS。
那么真的，控制RPS的方法是什么？我在这里遗漏了一些明显的东西吗？

Answer 1

(这里的蝗虫作者之一)

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

我知道追求某个 RPS 数字很诱人，有时我也会通过追求任意 RPS 数字来“欺骗”。

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

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