扩容EC2实例后AWS ALB与EC2仍存性能问题，求排查建议

环境配置 #

• AWS负载均衡器：Application Load Balancer (ALB)
• EC2实例：初始2台large实例，已扩容至7台large实例
• 数据库：AWS DocumentDB，实例类型xlarge
• 测试工具：JMeter，模拟520个线程，每个线程每分钟发起10次API调用

问题现象 #

• JMeter测试显示单请求平均响应时间超过10秒，扩容EC2实例后无明显改善，部分场景性能反而下降

已排查项 #

• EC2实例CPU及内存未达峰值
• ALB健康检查配置正确，所有实例状态健康
• 未启用粘性会话
• DocumentDB索引配置正确，已升级至xlarge实例并使用2个副本，CPU及内存使用率均正常

排查方向及建议 #

1. 网络流量与分发排查 #

• ALB流量均衡性：通过CloudWatch查看RequestCountPerTarget指标，确认7台EC2实例的请求分发是否均匀，若存在部分实例请求量极低的情况，需检查目标组规则或ALB路由配置
• VPC网络链路：验证EC2与DocumentDB是否处于同一VPC/可用区，跨可用区或跨VPC会引入额外网络延迟；查看EC2的NetworkIn/NetworkOut、DocumentDB的NetworkBytesIn/NetworkBytesOut指标，排查是否存在带宽瓶颈；检查安全组、网络访问控制列表（NACL）是否存在不必要的规则限制
• 区域网络性能：若EC2和DocumentDB分属不同区域，优先调整至同一区域部署，跨区域网络延迟会直接影响请求响应时间

2. 应用与数据库连接层排查 #

• 数据库连接池配置：检查EC2上应用的DocumentDB连接池参数（如最大连接数、空闲连接超时），若连接数过少会导致请求排队，过多则可能引发数据库端连接竞争；结合CloudWatch的DatabaseConnections指标验证
• 应用线程池配置：确认应用自身的线程池（如Web容器的maxThreads）是否限制了并发处理能力，若线程数不足，扩容EC2也无法充分利用实例资源
• 请求链路串行操作：排查单个API请求内部是否存在串行的DocumentDB操作或依赖外部服务的阻塞逻辑，这类单请求内部的瓶颈无法通过扩容EC2解决

3. ALB配置细节排查 #

• 空闲超时设置：检查ALB的空闲超时时间（默认60秒），若应用处理请求耗时超过该值，会导致连接断开并重试，增加整体延迟；查看CloudWatch的TargetResponseTime及HTTP_5xx指标，排查超时类错误
• SSL/TLS协议开销：若使用HTTPS，查看SSLNegotiationErrorCount指标，排查SSL握手是否存在异常；确认是否开启HTTP/2，协议不匹配可能导致性能损耗
• 连接复用配置：检查目标组的连接复用设置，未开启连接复用会导致频繁建立新连接，增加额外开销；查看ConnectionReuseCount指标验证

4. 全链路监控与日志分析 #

• 开启X-Ray全链路追踪：通过AWS X-Ray追踪单个请求从ALB到EC2再到DocumentDB的各环节耗时，准确定位延迟最高的节点
• 应用日志分析：收集EC2上的应用日志，排查是否存在慢查询、资源等待（如等待数据库连接）或错误信息
• DocumentDB慢查询日志：开启DocumentDB的慢查询日志，检查是否存在未优化的查询（如全表扫描、复杂聚合），这类查询可能CPU使用率不高但单请求耗时过长

内容的提问来源于stack exchange，提问作者kuan tein