我需要在 10 分钟的测试窗口中使用 accust模拟 20,000(及更高(用户。
蝗虫文件是 9 个 API 调用的任务。 我正在尝试确定理想的工作线程数量，以及应将多少工作线程附加到 AWS 上的 EC2。 我的测试显示，在两个 EC2 实例上有 20 个工作线程时，CPU 负载最小。 然而，主人遭受了很大的痛苦。 一个 4 CPU 16 GB RAM 系统作为主站最终崩溃到工人开始打印如下消息的地步：
[2020-06-12 19:10:37,312] ip-172-31-10-171.us-east-2.compute.internal/INFO/locust.util.exception_handler: Retry failed after 3 times.
[2020-06-12 19:10:37,312] ip-172-31-10-171.us-east-2.compute.internal/ERROR/locust.runners: RPCError found when sending heartbeat: ZMQ sent failure
[2020-06-12 19:10:37,312] ip-172-31-10-171.us-east-2.compute.internal/INFO/locust.runners: Reset connection to master
主进程似乎耗尽了内存，因为每个蝗虫主进程都已增长到 12GB 虚拟 RAM。 好的 - 所以EC2有问题。 但是，如果我需要测试20,000个用户，那么地球上是否有足够大的机器来处理这个问题？ 还是我需要采取不同的方法，如果是这样，建议的方向是什么？
在我的特定情况下，其中一个步骤是从 CloudFront 下载一个文件，该文件在其中一个任务中随机选择。 这意味着尝试下载文件的 cloudFront 连接越开放，可用网络就越拥塞。
由于应用程序客户端实际上是移动设备上的本机应用程序，并且有很多因素会影响每个移动设备的下载速度，因此我决定从GET请求切换到HEAD请求。 这允许我测试来自 CloudFront 的响应时间，其中分配受Lambda@Edge函数保护，该函数使用测试早期的数据对用户进行身份验证。
这样做可以显著改善负载测试结果，并且不会像带宽或系统资源耗尽那样人为地扭曲其他测试，其他所有测试都会受到负面影响。
使用这种方法，我在十分钟的运行时间内成功执行了 10,000 个用户测试。 我使用了 4 个 EC2 T2.xlarge 实例，每个 T2 有 4 个工作线程。 测试计划中 9 个任务产生了近 750,000 次 URL 调用。
标题中问题的答案是："视情况而定">
你的帖子有点混乱。你说你有 10 个主流程？为什么？
这个问题很可能与master完全无关，因为它不关心下载的大小(这似乎是你的测试用例和大多数其他蝗虫测试之间的唯一区别(
有一些一般提示可能会有所帮助：
- 切换到 FastHttpUser (https://docs.locust.io/en/stable/increase-performance.html(
- 监控您的网络使用情况(如果您的负载生成器已经最大化了其带宽或 CPU，那么您的测试无论如何都是非常不现实的，添加更多用户只会增加噪音。一般来说，从低处开始，然后逐步上升(
- 增加负载生成器的数量
一般来说，用户数量不是蝗虫的问题，但每秒的请求数或带宽可能是问题。