wrk多级并发压测配合Nginx日志与系统指标观测可验证轮询真实吞吐：需部署带唯一标识的后端服务，阶梯式提升并发（100→500→1000→2000），记录QPS及P50/P95延迟；通过access.log统计请求分布，偏差应≤±5%；同步用htop、ss、vmstat等排查CPU、连接数、上下文切换等瓶颈。
直接用 wrk 做多级并发压测，配合 Nginx 日志统计与系统指标观测，就能看清轮询在不同并发下的真实吞吐表现。它本身开销极低，瓶颈往往不在算法，而在连接复用、后端响应或系统限制。
准备可区分的后端服务
让每台后端返回唯一标识（如端口号或主机名），便于后续统计请求分布：
- 启动至少两台服务，例如 Python 快速起站：
python -m http.server 8081和python -m http.server 8082 - 每台服务根路径返回明确文本，如
Server-8081和Server-8082 - Nginx upstream 配置保持默认轮询，不加 weight 或其他策略
分档压测并记录 QPS 与延迟
用 wrk 按阶梯提升并发量（如 100 → 500 → 1000 → 2000），每次运行足够时间以稳定数据：
- 命令示例：
wrk -t4 -c100 -d60s --latency http://nginx-ip/（4线程、100并发、60秒） - 重点记录输出中的 Requests/sec（吞吐）和 P50/P95 延迟
- 当 P95 / P50 > 4 时，说明长尾明显，需查是否某后端拖累或调度不均
验证轮询是否真正均匀分发
压测过程中实时检查后端日志或用 awk 统计 Nginx access.log 中各后端 IP 的请求数：
- 命令示例：
awk '{print $NF}' access.log | sort | uniq -c | sort -n - 理想情况下，各节点请求数偏差应控制在 ±5% 内
- 若偏差过大，检查是否某台后端响应超时导致 Nginx 临时剔除（需确认 max_fails/fail_timeout 是否配置）
同步观测系统资源水位
吞吐不是孤立数字，必须结合 CPU、网络、连接状态交叉判断瓶颈位置：
- 用
htop观察各 CPU 核心负载是否均衡；差异超 40% 可能是 worker_cpu_affinity 未生效 - 用
ss -s查 total connections，对比net.core.somaxconn是否足够 - 用
vmstat 1关注 cs（上下文切换）和 r（运行队列），r 值持续 > CPU 核数说明调度已饱和
