为何单EC2实例（PHP+Laravel）响应远慢于ALB+Lambda架构？

测试环境 #

• 基于PHP 8.2 + Laravel 10.2构建的API服务
• 两种部署架构对比：
  1. 应用负载均衡器（ALB）+ Lambda：通过example.com/api/*路径对外提供服务
  2. 单台t3.small EC2实例：配置Nginx反向代理，将example.com/api/*请求转发至运行API的Docker容器
• 两种架构共享同一VPC内的AWS RDS MySQL实例

测试工具与命令 #

使用vegeta工具执行负载测试，命令如下：

echo "GET https://$host/api/load-data" | vegeta attack -rate=20/s -duration=10s | tee "$resultsFile" | vegeta report

EC2测试结果 #

测试表现极差，响应时间立即飙升：

Requests      [total, rate, throughput]         200, 20.10, 8.48
Duration      [total, attack, wait]             16.5s, 9.95s, 6.55s
Latencies     [min, mean, 50, 90, 95, 99, max]  501.875ms, 5.961s, 6.648s, 7.45s, 7.556s, 7.94s, 8.252s
Bytes In      [total, mean]                     4239103, 21195.51
Bytes Out     [total, mean]                     0, 0.00
Success       [ratio]                           70.00%
Status Codes  [code:count]                      200:140  429:60  
Error Set:
429 Too Many Requests

注：EC2 CPU使用率始终未超过8-9%，已配置无限CPU信用且余额为正，空闲内存超过1GB

ALB+Lambda测试对比 #

相同测试参数（20请求/秒，持续10秒）下，该架构表现优异，响应时间稳定无飙升（后续将补充具体测试结果）

排查进展（更新） #

通过Newrelic APM进一步分析后发现：

• MySQL并非性能瓶颈，负载状态下响应时间始终≤200ms
• 超过6秒的耗时集中在PHP内部，Laravel追踪显示大部分时间消耗在Custom/Illuminate\Foundation\Application::boot方法中，疑似文件系统I/O过载，但EC2监控未提供磁盘写入字节数数据，无法直接验证该猜想

核心问题与解决目标 #

EC2实例CPU、内存资源充足的情况下，为何会出现响应时间飙升和429限流？需要定位并解决该瓶颈，使EC2架构在相同吞吐量下达到ALB+Lambda组合的稳定响应表现

内容的提问来源于stack exchange，提问作者Kristi Jorgji