如何优化 Nginx+PHP-FPM 性能配置

在高并发的电商抢购或 API 网关场景里，Nginx 与 PHP‑FPM 的协同效率往往决定了整个系统的响应上限。若只把两者当作“装饰”，不深入挖掘底层参数的交互，常常会出现 CPU 飙到 100% 而 QPS 仍停留在几百的尴尬局面。于是，围绕硬件瓶颈、网络栈以及进程调度三大维度，重新审视配置文件，往往能把吞吐量提升 2‑3 倍。

核心调优思路

先让系统告诉你真实的资源上限：nproc 能看到 CPU 核心数，ulimit -n 揭示文件描述符上限。接下来，围绕这两个数字去匹配 Nginx 与 PHP‑FPM 的并发模型，别让任何一环成为瓶颈。

• worker_processes：设为 auto 或等于 CPU 核心数，确保每核都有独立的事件循环。
• worker_connections：结合 ulimit -n，常取 1024 * 核心数，让单进程可同时处理上万连接。
• keepalive_timeout：调低到 15‑20 s，既能复用 TCP，又不让空闲连接占用工作进程。
• fastcgi_buffers / fastcgi_busy_buffers_size：依据业务响应大小（如 64KB）设置，避免频繁的磁盘 swap。
• php‑fpm pm 参数：pm = dynamic，pm.max_children = (Total RAM - Cache) / Avg PHP Process Memory，再配合 pm.start_servers、pm.min_spare_servers、pm.max_spare_servers 形成弹性池。

# /etc/nginx/nginx.conf
worker_processes auto;
events {
    worker_connections 4096;
    multi_accept on;
}
http {
    keepalive_timeout 15;
    fastcgi_buffer_size 64k;
    fastcgi_buffers 8 64k;
    fastcgi_busy_buffers_size 128k;
}

实战案例：从 350 RPS 到 950 RPS

某金融公司在 8 核 16 GB 机器上跑 PHP‑Laravel，原始配置 worker_processes 1、pm.max_children 20，压力测试仅能维持 350 RPS，CPU 负载却逼近 90%。按照上面的思路改为 worker_processes 8、pm.max_children 120，并把 worker_connections 调至 8192，整体 QPS 直接冲到 950，CPU 利用率回落到 55%。这并不是硬件升级的奇迹，而是把并发模型与资源匹配得更紧密。