设置：EC2 服务器在 ELB 后面自动扩展，连接到 RDS mysql 数据库，所有静态文件都从 Cloudfront 提供。
我在 EC2 服务器上运行 nginx 作为 Web 服务器，keepalive 设置为 20，工作进程 4，.Codeigniter 是后端，使用 codeigniter 会话。
我一直在运行很多基准测试来尝试测试性能、围攻、apache 基准测试 blitz.io。
我正在测试两个特定的页面，第一个性能非常好，它使用代码点火器会话，因此命中数据库以读取和更新ci_sessions数据库。第二页是我遇到问题的页面，它运行一个具有多个连接的查询，单个用户在大约 0.4 秒内完成。此查询已优化，我正在使用 InnoDB 表。在 c10 和 n1000 的 apache 基准测试下，100% 的请求在 634 毫秒内返回。
当我运行并发用户> 200 时，我开始遇到问题。添加更多的 EC2 服务器无济于事，CPU 利用率约为 50%。RDS 数据库监控还显示 CPU 和内存使用率低于 70%，平均数据库连接数<35。
通过迁移到大型 RDS 实例和大型 EC2 实例，性能得到了提高，这让我想知道 I/O 是否在这里发挥作用。
如果我在负载测试期间在 ELB 之外启动服务器并点击此页面，它会在不到一秒的时间内返回，但如果我在 ELB 中启动另一台服务器，它最多需要 4 或 5 秒。这表明我没有使 RDS 过载。
我尝试以 5 分钟的爆发缓慢增加 ELB，但这似乎没有帮助。
我想知道接下来要在哪里寻找这个问题，无论是某种I/O问题还是其他问题，因为RDS和EC2服务器似乎没有被推到它们的能力。任何建议或想法，下一步将不胜感激
好的。嗯，如你所知，这是一个非常广泛的主题。但我会尽力提供帮助。
-
ELB 通常不太擅长突发缩放。在与亚马逊工程师讨论此事后，我发现他们实际上不会在突发时扩展 ELB，因为这是不可能的。您需要随着时间的推移保持一致的负载才能使 ELB 纵向扩展。正因为如此，我改用了haproxy。除了 ELB 不会在突发负载上扩展之外，它还使用 CNAME 进行 DNS 查找，这也会影响您的性能。因此，如果您计划经常进行突发负载或要求DNS查找，则最好摆脱ELB。
-
RDS是一个黑匣子。好吧，这并不完全正确，但总的来说，除非我知道后端是易于扩展的简单设置，否则我会避免使用 RDS。话虽如此，RDS 确实有助于扩展，但我会降低后端并确保您的查询快速运行。在常规MySQL实例上运行它，看看它是否是亚秒级。根据我的经验，当您说查询已"优化"时，这并不意味着如果您发现我的漂移，就没有其他方法可以使其更加"优化"。