Nginx多进程架构不直接承受压测流量，而是作为高并发请求的分发与处理枢纽；压测核心是验证其在真实负载下能否稳定高效调度连接、转发请求并支撑预期并发规模。
Nginx 的多进程架构本身不直接“承受”压测流量，而是作为高并发请求的分发与处理枢纽。压力测试的关键，是验证这个架构在真实负载下能否稳定、高效地调度连接、转发请求、避免瓶颈，并支撑预期的并发规模。测试不是测 Nginx 多进程“有没有”，而是测它“能不能扛住”。
明确 worker_processes 与实际并发能力的关系
Nginx 默认单 worker 进程，但生产环境必须显式配置多进程。每个 worker 是独立的单线程事件循环（基于 epoll/kqueue），不共享内存，靠操作系统调度。总并发能力 ≈ worker_processes × worker_connections。比如 8 核机器设 worker_processes 8、worker_connections 65535，理论最大连接数约 52 万——但这只是上限，实际受系统资源、后端响应、网络吞吐制约。
压测前必须调优的三项核心参数
-
worker_processes auto;或明确设为 CPU 核心数（如8），避免过多进程引发调度开销； -
worker_cpu_affinity auto;让每个 worker 绑定到专属 CPU 核心，减少缓存失效和上下文切换； -
worker_rlimit_nofile 1048576;配合系统级文件句柄限制（ulimit -n至少设为 100 万），否则大量连接会报Too many open files。
用 ab 或 wrk 模拟真实连接压力
简单轮询压测不能暴露多进程瓶颈，需组合参数逼近真实场景：
- 用
ab -n 100000 -c 5000 http://ip/测试短连接吞吐，观察Requests per second是否随并发线性增长； - 用
wrk -t8 -c4000 -d60s --latency http://ip/测试长连接（keepalive），更贴近多进程复用连接的典型行为； - 同时监控
nginx -s reload后各 worker 进程的 CPU 占用（top -p $(pgrep nginx | head -n 8 | xargs)），确认负载是否均匀。
识别多进程架构下的典型瓶颈点
- 所有 worker 进程 CPU 均接近 100%，但 QPS 不再上升 → 瓶颈在后端或网络带宽；
- 某几个 worker CPU 高、其余偏低 → 可能存在连接分配不均（检查
accept_mutex on;是否启用，默认开启，可防惊群）； - 出现大量
502或超时 → upstream 超时设置过短，或后端响应慢导致 worker 阻塞； -
TIME_WAIT连接堆积 → 调整内核参数net.ipv4.tcp_tw_reuse = 1，并确保keepalive_timeout不设过长。
配合日志与指标做进程级归因
在 log_format 中加入 $pid 和 $msec，例如：
log_format perf '$pid - [$time_local] "$request" $status $upstream_response_time $request_time';
压测时用 awk '{print $1}' access.log | sort | uniq -c | sort -nr 查看各 worker 进程处理请求数是否均衡；再结合 nginx_stub_status 模块输出的 Active connections、Reading/Writing/Waiting 状态，判断是连接建立、读取请求、还是等待后端响应成为主要耗时阶段。
