我在负载均衡器后面有一组 EC2 t1.micro 实例，每个节点在开始出现问题之前可以管理大约 100 个并发用户。
我认为如果我有 2 个这样的实例，我的网络就可以管理 200 个并发用户……显然不行。当我真正用 275 个并发用户猛击服务器 (blitz.io) 时，它的行为与只有一个节点时相同。响应时间从 400 毫秒缩短到 1.6 秒（对于单个 t1.micro 来说是预期的，但不是 6）。
所以问题是，我是不是做错了什么，或者 ELB 实际上毫无价值？有人对此有什么见解吗？
AB 日志：
负载均衡器（3x m1.medium）
文档路径：/ping/index.html
文档长度：185 字节
并发级别：100
测试时间：11.668 秒
完成请求数：50000
失败请求：0
写入错误：0
非 2xx 响应：50001
总共传输：19850397 字节
HTML 已传输：9250185 字节
每秒请求数：4285.10 [#/秒]（平均）
每个请求的时间：23.337 [毫秒]（平均）
每个请求的时间：0.233 [毫秒]（所有并发请求的平均值）
传输速率：已接收 1661.35 [千字节/秒]
连接时间（毫秒）
最小平均值[+/-标准差] 中位数 最大值
连接：1 2 4.3 2 63
处理：2 21 15.1 19 302
等待：2 21 15.0 19 261
总计：3 23 15.7 21 304
单实例（1x m1.medium 直接连接）
文档路径：/ping/index.html
文档长度：185 字节
并发级别：100
测试时间：9.597 秒
完成请求数：50000
失败请求：0
写入错误：0
非 2xx 响应：50001
总共传输：19850397 字节
HTML 已传输：9250185 字节
每秒请求数：5210.19 [#/秒]（平均）
每个请求的时间：19.193 [毫秒]（平均）
每个请求的时间：0.192 [毫秒]（所有并发请求的平均值）
传输速率：已接收 2020.01 [Kbytes/sec]
连接时间（毫秒）
最小平均值[+/-标准差] 中位数 最大值
连接：1 9 128.9 3 3010
处理：1 10 8.7 9 141
等候：1 9 8.7 8 140
总计：2 19 129.0 12 3020
答案1
微型实例并非为持续负载而设计的。它们允许 CPU 爆发，但在负载过重的短时间（例如 15-30 秒）后，它们将严重上限。
如果您想要任何有用的基准，请至少用一个小实例尝试一下。
答案2
确保您没有意外选择粘性负载平衡。这会导致同一用户被定向到同一实例。
微型实例并非为承受重负载而设计的。它们是为了应对 CPU 爆发而设计的。不过我可以向你保证，微型实例可以很好地与弹性负载平衡配合使用。
别忘了还有其他方法可以增加网站可以处理的流量。例如 Varnish
答案3
检查单个服务器上的负载。当流量来自单个 IP 时（如 AB 测试用例中所示），ELB 不会将流量均衡地分配到所有实例：它只会从一个实例切换到另一个实例。最终负载不可能是单个实例的两倍，但平均而言，这无论如何都比将所有流量导向单个实例要好（因为这样可以减少负载并加快响应速度）
答案4
这里的问题是 ELB 本身。前段时间我们进行了一些性能测试，发现当每秒请求数超过 250 个时，ELB 开始出现很大的延迟。我们在测试 ELB 时发现了这一点，然后针对 ELB 后面的一个实例进行这些测试 - 该实例（m1.large 实例类型）在每秒 250 个请求的情况下运行良好（尽管有一些负载），而后面有几个实例的 ELB 正在崩溃。同时，在测试 ELB 时，实例的负载很小。
我的建议是获取一个可充当其他实例的负载均衡器的实例（最好为此配置 nginx），并且不使用任何 ELB。