8

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

实验信息

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

蝗虫.io

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

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

Locust.io 吞吐量图

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

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

4

2 回答 2

7

（这里的蝗虫作者之一）

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

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

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

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

于 2014-12-31T04:11:34.840 回答
1

虽然没有直接控制 rps 的方法，但您可以尝试constant_pacing并constant_throughput选择wait_time

来自文档 https://docs.locust.io/en/stable/api.html#locust.wait_time.constant_throughput

在以下示例中，无论任务执行时间如何，任务总是每 1 秒执行一次：

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

constant_pacing与此相反。

因此，如果您运行 100 个并发用户，测试将以 100rps 运行（假设每个请求首先花费不到 1 秒

于 2022-02-01T04:36:27.407 回答