并发上不去？从 requests per second 偏低倒查 Nginx 配置

先分清是「压不上去」还是「服务接不住」

requests per second 偏低，第一件事不是改配置，而是判断瓶颈在压测端还是服务端。压测机自己 CPU 跑满、端口耗尽、ulimit 太小，都会让结果虚低。

简单的办法：压测时同时看两端的 CPU、网络和连接状态。如果压测机 CPU 先到 100%，换台机器或用分布式压测；如果服务端 CPU 不高但 QPS 上不去，那才轮到查 Nginx。

还有一种情况最迷惑人——服务端 CPU 不高、网络也不忙，但延迟很高。这通常是等待，比如回源慢、磁盘 IO 卡、或者日志同步写盘。

按这条路径一层层查

第一层：连接数上限。看 ss -s 的 TIME_WAIT 和 ESTAB 数量，对照 worker_connections × worker_processes 的总量。到顶了就先调连接，再谈别的。

第二层：日志。access_log 每条请求都写盘，高并发下磁盘 IO 会成为瓶颈。做法是开 buffer、批量刷盘，或者把日志丢到独立盘。压测阶段甚至可以先关日志，确认是不是它拖的。

第三层：DNS 与 upstream。proxy_pass 里写域名而不是 IP，每个请求都可能触发解析；upstream 没配 keepalive，回源全是短连接。这两点在中大型站点里非常常见。

• access_log 加 buffer=32k flush=5s
• upstream 内配置 keepalive 连接池
• proxy_pass 优先用 IP 或 upstream 名称
• 静态资源交给 Nginx，别转发给后端

硬件与线路同样是变量

同一份配置，放在不同机器上结果可能差一倍。CPU 主频、内存带宽、网卡队列、磁盘类型都会影响。做反向代理和静态分发时，带宽和 IO 往往比核数更关键。

面向北美用户的业务，如果回源和分发都走公网，线路质量直接决定 P99。美国洛杉矶物理服务器4 这类 100M 带宽的独立服务器，在跑 Nginx 反代和静态分发时，网络侧不容易先成为瓶颈，配置调优的效果也更容易体现出来。

把结果沉淀成基线

每次压测记录：并发数、QPS、P50/P99 延迟、错误率、两端资源占用。形成基线后，任何配置改动都能对比。别追求一次调到极致，先找到当前最大的那块短板，解决它，再进入下一轮。