小编sid*_*idi的帖子

我一直在尝试使用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个字节.请求失败率:<1%,平均响应时间为6ms.

变量:连续请求设置为450毫秒(最小值:100毫秒和最大值:1000毫秒)之间的时间,填充率为每秒30秒,以及通过改变#_users测量的RPS.

RPS遵循预测的方程,最多可达1000个用户.之后增加#_users的收益递减,大约1200个用户达到上限.#_users这里不是自变量,更改等待时间也会影响RPS.但是,将实验设置更改为32个核心实例(c3.8x实例)或56个核心(在分布式设置中)根本不会影响RPS.

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