构建nginx基线性能数据本质是建立可复现的“健康常态”参考标尺，需分场景（静态资源、反向代理、配置变更）压测，用wrk规范执行（-t4 -c1000 -d180s --latency）、物理分离客户端与服务器、清空缓存，并同步采集qps、p50/p95延迟、cpu%us及内核瓶颈信号，最后固化归档并定期校准。
构建 Nginx 基线性能数据，本质是用可复现的方式测出它在当前环境下的“健康常态”，不是追求极限值，而是建立一个能反映真实负载能力、便于后续对比的参考标尺。
明确测试目标与范围
基线不是一次测完就一劳永逸，而是按场景分层建立：
- 静态资源吞吐基线：用最小 HTML 文件（如 2KB index.html）压测，排除后端干扰，聚焦 Nginx 自身 HTTP 处理能力
- 反向代理基线：后端挂真实服务（如 httpbin），测带转发链路的延迟与吞吐，关注 upstream 耗时和连接复用效果
- 配置变更影响基线：比如调 worker_processes、keepalive_timeout 或 gzip 开关，每次只改一项，其他全固定
选对工具并规范执行
ab 适合快速初筛，wrk 是构建可信基线的主力：
- 用
wrk -t4 -c1000 -d180s --latency http://nginx-host/运行至少 3 分钟，避免瞬时抖动；加--latency才能拿到 P50/P95 数据，这对发现长尾问题很关键 - 避免用本机压测本机，客户端和 Nginx 必须物理分离，且同局域网直连（推荐万兆），否则网络栈争抢会污染结果
- 每次运行前执行
sync && echo 3 > /proc/sys/vm/drop_caches，清空页缓存、dentry 和 inode 缓存，确保文件读取不走内存缓存
同步采集多维指标
单看 QPS 容易误判。基线必须包含三类同步观测项：
- 响应指标：QPS、平均延迟、P50/P95/P99 延迟（重点关注 P95 是否突增 30%+）
-
系统资源：Nginx worker 进程 CPU 用户态（%us）、内存 RSS、上下文切换数（
pidstat -w -p $(pgrep nginx)） -
内核瓶颈信号：检查
netstat -s | grep -i "retransmit\|drop"看是否有丢包或重传；用ss -s观察已用 file descriptor 数是否逼近 ulimit 上限
固化基线并定期校准
基线不是存档就完事，要形成闭环：
- 把每次压测的完整命令、Nginx 版本、内核参数（如 net.core.somaxconn）、CPU/内存配置、采集指标截图打包归档
- 上线新配置或升级版本前，必须跑同一套脚本比对基线，差异超过 10% 就需回溯原因
- 每季度用相同方法复测一次，验证硬件老化、内核更新或流量模式变化是否导致基线漂移
