平滑重载不降低服务可用性，但需压测验证重载瞬间请求是否被丢弃、延迟突增或返回异常；必须用长连接持续施压、在压测中执行reload、检查error日志；核心指标包括failed requests、time per request峰值及complete requests总数；推荐wrk、tcpdump和进程监控辅助验证。
平滑重载本身不改变服务可用性，但重载瞬间的请求处理是否平稳，需要靠压测来验证。关键不是“测重载动作”，而是测重载过程中真实请求是否被丢弃、延迟突增或返回异常。
压测前必须准备的三件事
确保测试能真实反映重载行为：
-
用长连接持续施压：ab 默认短连接，无法暴露重载时 worker 进程切换带来的连接抖动。务必加
-k参数启用 HTTP Keep-Alive，例如：ab -n 10000 -c 200 -k http://your-domain/ -
让压测流量贯穿重载全过程：启动 ab 后，在它运行中（比如第 3000 次请求左右）立即执行
nginx -s reload，而不是先 reload 再开压测 -
检查 Nginx 日志是否记录异常：临时开启
error_log /var/log/nginx/error.log notice;，reload 后快速翻看日志，重点关注recv() failed、upstream prematurely closed或worker process exited类报错
观察重载瞬间的核心指标
ab 输出里真正有用的不是平均 QPS，而是重载发生时的局部表现：
Apache Superset Dashboard and SQL Exploration Skill
下载
Apache Superset 是一个广泛采用的开源 BI 平台，用于 SQL 探索、图表构建和仪表板交付。当代理需要查询仓库数据、组装仪表板或使用成熟的分析界面解释指标而不是临时笔记本代码时，此技能非常有用。
- Failed requests 是否非零：哪怕只有 1~2 个失败，说明有请求在旧进程关闭、新进程尚未完全接管的间隙被丢弃
-
Time per request 的最大值（ms）是否飙升：ab 不直接输出最大延迟，但可配合
-g生成详细时间戳数据，用awk '{print $3}' | sort -nr | head -1提取峰值延迟。若从 2ms 跳到 800ms，大概率是某次请求卡在 reload 过程中 -
Complete requests 总数是否等于预期：如果设了
-n 10000却只完成 9997，缺失的 3 个很可能就发生在 HUP 信号发出后的几百毫秒内
比 ab 更准的验证方式
ab 是入门工具，对重载瞬态不够敏感。建议补充以下任一方法：
-
用 wrk 持续采样：启动
wrk -t4 -c500 -d30s --latency http://your-domain/，在第 15 秒手动 reload，观察输出中每秒的 latency 分布变化 -
抓包确认连接状态：在压测机上
tcpdump -i any port 80 -w reload.pcap，reload 后分析 SYN/RST 包数量和时间点，看是否有批量 RST 出现 -
监控 Nginx 进程状态：执行
watch -n 0.1 'ps aux | grep nginx | grep -v grep'，reload 瞬间应短暂出现两个 master 进程（旧 + 新），且旧 worker 数量逐步归零——这是平滑的关键证据
重载是否真平滑，不取决于命令有没有报错，而取决于正在飞的请求有没有被截断。压测只是手段，目标是让每一次 reload 都像换轮胎一样，车还在跑。
