评估nginx在全链路压测中的抗压与自我恢复能力，核心是验证其在真实业务流中的稳定性、故障快速恢复性及扩容韧性；需紧扣短连接、突发脉冲、大body、https等实际流量特征设计压测场景，分层注入故障并采集active connections、upstream timeout、time_wait等关键信号，建立45分钟稳态压测与闭环分析机制。
评估 Nginx 在全链路压测中的抗压与自我恢复能力，核心不是看它能扛住多高 QPS，而是验证它在真实业务流里是否稳、出问题时是否快、扩容或故障后是否韧。
紧扣业务特征设计压测场景
脱离业务模式的压测结果没有参考价值。必须按实际流量画像来构造请求：
- 短连接 API（如移动端调用）：启用
-k关闭长连接，模拟每秒新建大量 TCP 连接，重点观察TIME_WAIT堆积和端口耗尽 - 突发脉冲（如秒杀、活动开抢）：用 wrk 或 k6 设置阶梯式 ramp-up，比如 30 秒内从 100 并发冲到 5000，并持续 2 分钟，检验 Nginx 是否出现连接拒绝或 upstream 轮空
- 大 Body 场景（如文件上传）：发送 2–10MB POST 请求，检查
client_max_body_size和 buffer 配置是否合理，避免日志中出现client intended to send too large body - HTTPS 高占比：开启 SSL/TLS 压测，监控 CPU 用户态中
openssl或ssl_handshake占比，超 40% 就需启用ssl_session_cache shared:SSL:10m和 OCSP stapling
分层注入故障，验证恢复时效性
高可用不等于“不坏”，而在于“坏了多久能好”。压测中要主动破坏、实时观测：
- 随机下线一台后端服务：观察 Nginx 的
max_fails=3 fail_timeout=30s是否在 1–2 秒内将该节点标记为unavailable，且错误率不飙升 - 人工制造慢响应：用
sleep 3模拟某台后端 P95 延迟突增至 3s，确认 Nginx 是否因proxy_read_timeout触发重试，以及重试是否导致其他节点连锁过载 - 模拟网络抖动：在后端机器上用
tc qdisc add dev eth0 root netem delay 200ms 50ms加入延迟波动，验证 Nginx 是否仍能维持 P99 ≤ 300ms - 恢复验证：等故障节点重启后，检查 access 日志中是否在 30 秒内重新收到其响应，且无重复请求或 502 波动
采集关键信号，识别隐性瓶颈
不能只盯 QPS 和平均延迟，要抓 Nginx 自身暴露的“压力语言”：
-
Active connections 持续 > worker_connections × worker_processes × 0.8：说明连接堆积，大概率是 upstream 处理不过来，或
keepalive_timeout设得太长 - access 日志中频繁出现
upstream timed out：优先调低proxy_connect_timeout（建议 3–5s）和proxy_read_timeout（建议 10–15s），再查后端 GC 或 DB 锁 - error 日志报
upstream sent too big header：立刻调大proxy_buffer_size 8k和large_client_header_buffers 4 16k - 运行
ss -s | grep "TCP:"发现tw数超 3 万，且net.ipv4.tcp_tw_reuse = 0：说明 TIME_WAIT 无法复用，需开启内核参数并确认客户端未强制关闭 keepalive
建立闭环验证机制
单次压测只是快照，持续稳定才反映真实能力：
- 跑 45 分钟稳态压测（目标 QPS 的 75%），观察 Nginx worker 进程 RSS 内存是否缓慢上涨——若 30 分钟内增长超 15%，提示存在连接泄漏或缓存未释放
- 对比直连后端 vs 经 Nginx 转发的 P95 延迟差值：若差值 > 15ms，检查
tcp_nodelay on是否生效、网卡软中断（si）是否超 70% - 记录每次压测前后
nginx_stub_status输出：重点关注Reading（Nginx 读取请求头阶段）、Writing（向后端转发或向客户端回包阶段）比例突变，可定位是解析慢还是转发慢 - 用
perf record -p $(pgrep nginx) -g -a sleep 30抓热点，确认 CPU 是否卡在 SSL、regex 或日志刷盘路径上
