我在负载均衡器后面有一组EC2 t1.micro实例，每个节点可以pipe理大约100个并发用户，然后开始变得不可靠。
我会想，如果我有2个这样的实例，它将允许我的networkingpipe理200个并发用户…显然不是。 当我真的用服务器（blitz.io）完全冲击275个并发时，它的行为就像只有一个节点一样。 它从400ms响应时间到1.6秒（对于单个t1.micro是预期的，而不是6）。
所以问题是，我是不是在做正确的事情，或者ELB实际上是毫无价值的？ 任何人都有这方面的一些智慧？
AB日志：
Loadbalancer（3x m1.medium）
文档path：/ping/index.html
文件长度：185字节
并发级别：100
testing时间：11.668秒
完成请求：50000
失败的请求：0
写错误：0
非2xx响应：50001
转移总数：19850397字节
HTML传输：9250185字节
每秒请求数：4285.10 [＃/秒]（平均值）
每个请求的时间：23.337 [ms]（平均值）
每个请求的时间：0.233 [ms]（意味着跨所有并发请求）
传输速率：1661.35 [千字节/秒]收到
连接时间（ms）
分钟平均值[+/- sd]中值最大值
连接：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直接连接）
文档path：/ping/index.html
文件长度：185字节
并发级别：100
testing时间：9.597秒
完成请求：50000
失败的请求：0
写错误：0
非2xx响应：50001
转移总数：19850397字节
HTML传输：9250185字节
每秒请求数：5210.19 [＃/秒]（平均值）
每个请求的时间：19.193 [ms]（平均值）
每个请求的时间：0.192 [ms]（意味着跨所有并发请求）
传输速率：2020.01 [Kbytes / sec]收到
连接时间（ms）
分钟平均值[+/- sd]中值最大值
连接：1 9 128.9 3 3010
处理：1 10 8.7 9 141
等待：1 9 8.7 8 140
总计：2 19 129.0 12 3020
微型实例不适用于持续负载。 它们允许CPU爆裂，但是在很短的时间（想象15-30秒）之后，它们将会受到严重的封锁。
如果您想要任何有用的基准，至less可以用一个小实例来尝试。
确保你没有意外select粘性负载平衡。 这将导致相同的用户被定向到相同的实例。
微型实例不是为了承受重负载而devise的。 他们是为CPU爆裂。 我可以向你保证，虽然微型实例工作正常弹性负载平衡。
不要忘记，可能有其他方式来增加您的网站可以应付的stream量。 例如。 漆
检查单个服务器上的负载。 当来自单个IP（如在ABtesting案例中）时，ELB并不平衡地平衡所有实例的stream量：它只是从一个实例切换到另一个实例。 最后的负载不能是单个实例的两倍，但平均来说，最好的方法是将所有stream量导向一个实例（由于减less了负载和响应速度）
这里的问题是ELB本身。 前一段时间，我们做了一些性能testing，发现当每秒钟超过250个请求时，ELB开始有很大的延迟。 我们在testingELB时发现了这一点，然后对ELB背后的一个实例进行这些testing – 实例（一个m1.large实例types）以250个请求/秒的速度运行良好（尽pipe有一些负载），而ELB在它后面的一些事例正在死亡。 同时，在testingELB时，实例几乎没有负载。
我的build议是获得一个实例作为一个负载平衡器（最好为此configurationnginx）为其他实例，不使用任何ELB。