在把业务从物理机迁移到云服务器的过程中，Web应用响应速度的变化往往最容易暴露问题。同一个Nginx加PHP的架构，在本地测试时QPS能到几千，搬到阿里云ECS上却可能腰斩，这背后既有虚拟化带来的开销，也有实例规格、操作系统参数、应用配置不匹配的原因。为了搞清楚不同配置的阿里云ECS到底能扛多少Web请求，我搭建了一套最小化的Web服务环境，使用wrk压测工具对三档主流规格进行了横向对比。测试重点放在QPS、响应时间分位数和CPU饱和度上，同时也验证了几项常见的系统调优是否真的有效。
一、测试环境与配置基线
这次测试选用了阿里云ECS通用型g7实例，规格分别是2核4G、4核8G和8核16G，操作系统统一使用Alibaba Cloud Linux 3.2104 LTS，内核版本5.10。Web服务采用Nginx 1.24.0作为反向代理和静态资源服务器，PHP 8.1.27通过PHP-FPM处理动态请求，数据库不部署在ECS上，而是使用同地域的云数据库RDS MySQL 8.0，避免本地磁盘I/O和数据库连接池成为测试干扰项。被压测的接口是典型的RESTful风格，返回一段JSON数据，逻辑包含一次Redis读取和一次MySQL查询，以模拟常规业务场景。
为了让结果具备可复现性，三台ECS都做了相同的初始化：关闭透明大页、调整文件描述符上限为65535、将Nginx的worker_processes设为auto，worker_connections设为1024。PHP-FPM的进程管理模式为dynamic，最大空闲进程数和最大子进程数按内存大小做了适配。以下是Nginx的核心配置片段，后续调优章节会基于它进行修改。
user nginx;
worker_processes auto;
error_log /var/log/nginx/error.log warn;
pid /run/nginx.pid;
events {
worker_connections 1024;
}
http {
include /etc/nginx/mime.types;
default_type application/octet-stream;
sendfile on;
keepalive_timeout 65;
server {
listen 80;
server_name _;
root /usr/share/nginx/html;
index index.php index.html;
location /api/bench {
fastcgi_pass 127.0.0.1:9000;
fastcgi_index index.php;
fastcgi_param SCRIPT_FILENAME $document_root/index.php;
include fastcgi_params;
}
}
}
这个配置没有针对高并发做任何优化，只保证服务能跑通。压测时使用wrk从同地域的另一台8核16G的ECS发起请求，避免公网带宽成为瓶颈，网络延迟控制在0.5ms以内。测试时长统一为60秒，预热10秒后开始统计。这些基线条件保证了后面不同规格之间的数据差异主要来自实例本身的CPU、内存能力以及软件配置。
二、基准测试结果与数据分析
压测命令如下，分别测试了100、200、400和800四种并发连接数，每个组合跑三轮取中位数。wrk的线程数固定为12，连接数对应变化，主要观察Requests/sec、平均延迟和P99延迟。
# 对2核4G实例执行400并发压测 wrk -t12 -c400 -d60s --latency http://10.0.0.10/api/bench
下表汇总了三种实例在400并发下的核心数据，完整结果按并发数梯度记录，这里仅展示最具代表性的档位。
| 实例规格 | 并发连接数 | QPS | 平均延迟(ms) | P99延迟(ms) | CPU使用率 |
|---|---|---|---|---|---|
| 2核4G | 400 | 1520 | 210 | 830 | 86% |
| 4核8G | 400 | 3200 | 105 | 350 | 68% |
| 8核16G | 400 | 4100 | 88 | 280 | 52% |
从数据可以看出，2核4G在100并发时已经接近CPU瓶颈，QPS在1800左右，当并发提升到400时平均延迟从54ms飙到210ms，P99超过800ms，CPU使用率长期处于85%以上，说明CPU调度已经跟不上请求堆积。4核8G的表现在400并发下相对从容，QPS能达到3200，P99控制在350ms以内，但继续增加到800并发时，QPS只略微涨到3400，延迟却翻倍，说明单机处理能力接近上限。8核16G的情况更典型：400并发时QPS约4100，800并发时仅提升到4300，CPU使用率约70%，但P99延迟从280ms升高到620ms，瓶颈已经不在CPU数量，而在Nginx和PHP-FPM之间的进程调度以及内核网络栈的锁竞争。
- 2核4G适合日均PV低于50万、峰值QPS不超过1500的轻量业务。
- 4核8G可覆盖多数中型Web应用，峰值QPS 3000以内时表现稳定。
- 8核16G适合预期峰值QPS 4000以上的场景，但必须配合调优才能发挥全部能力。
P99延迟对用户体验的影响远大于平均延迟，因为它反映了最慢的那1%请求的等待时间。如果P99超过500ms，说明部分用户已经能明显感知到卡顿，仅看平均延迟会掩盖掉长尾问题。
三、性能调优实践与避坑建议
针对方才暴露出的问题，我们在三台实例上应用了相同的调优方案，并重新跑了400并发基准测试。调优的核心思路是让Nginx与PHP-FPM的进程模型和系统内核参数匹配，而不是盲目提高单个数值。第一处调整是Nginx的events块，将worker_connections从1024提高到4096，并显式设置multi_accept on，使每个工作进程能一次接受多个新连接，减少系统调用次数。第二处是PHP-FPM的进程池，以4核8G实例为例，将pm.max_children从默认的20改为50，pm.start_servers设为20，pm.min_spare_servers设为10，pm.max_spare_servers设为30，同时确保每个PHP进程的内存上限不超过128MB。第三处是系统内核参数，执行以下命令。
# 调整内核网络参数 sudo sysctl -w net.core.somaxconn=65535 sudo sysctl -w net.ipv4.tcp_max_syn_backlog=8192 sudo sysctl -w net.ipv4.ip_local_port_range="1024 65535" sudo sysctl -w net.ipv4.tcp_tw_reuse=1 sudo sysctl -w fs.file-max=2097152 # 持久化配置 cat >> /etc/sysctl.conf << EOF net.core.somaxconn = 65535 net.ipv4.tcp_max_syn_backlog = 8192 net.ipv4.ip_local_port_range = 1024 65535 net.ipv4.tcp_tw_reuse = 1 fs.file-max = 2097152 EOF sysctl -p
调整完成后重启Nginx和PHP-FPM，再次执行相同压测。4核8G在400并发下QPS从3200提升到3900，P99从350ms降到180ms；8核16G在800并发下QPS从4300提升到5200，P99从620ms降到240ms。这说明之前的性能天花板确实存在于连接管理和进程调度层面，而不是实例本身的计算能力不够。
实际调优中有几个常见误区值得留意。第一，worker_processes设置过多，远超CPU核心数，反而增加上下文切换开销；第二，PHP-FPM的max_children开得太大，导致内存耗尽触发OOM，应该按可用内存除以单进程内存来估算；第三，忽视OPcache，导致每个请求都要重新编译PHP脚本，实测开启OPcache后QPS能提升30%以上；第四，在云环境下仍然使用默认的TCP参数，高并发下会出现大量TIME_WAIT状态占用端口，需要开启tcp_tw_reuse并扩大本地端口范围。通过这些调整，阿里云ECS作为Web应用服务器的性能上限能得到充分释放，选对规格再做好调优，完全可以支撑绝大多数生产级业务。