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

Question

我一直在尝试使用Locust.io在EC2计算优化实例上加载测试我的API服务器。它提供了一个易于配置的选项，用于设置连续请求等待时间和并发用户数。理论上， rps = 等待时间 X #_ users 。但是，在测试时，此规则会针对 #_ users 的极低阈值进行细分（在我的实验中，大约有1200个用户）。变量 hatch_rate ， #_ of_slaves ，包括在分布式测试设置中对 rps 几乎没有影响。

  

实验信息

     

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

     

Locust.io

     

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

     

变量：连续请求之间的时间设置为450毫秒（最小值：100毫秒和最大值：1000毫秒），孵化率为每秒30秒，而 RPS 通过改变 #_ users

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

那么真的，控制RPS的方法是什么？我有什么明显的遗失吗？

Answer 1

（这里有一位蝗虫作者）

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

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

但要回答你的问题，你确定你的蝗虫最终没有死锁吗？如同，他们完成了一定数量的请求然后变得空闲，因为他们没有其他任务要执行？没有看到测试代码就很难分辨出发生了什么。

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