nginx运行效能需综合连接状态、请求处理、资源消耗和业务表现四维度评估，核心是“连得上、接得住、转得快、撑得久”：活跃连接数、accepts/handled/requests比值、time_wait分布反映连接能力；$request_time的p95/p99、4xx/5xx错误分层、keepalive复用率体现请求处理效率；文件描述符使用率、cpu负载均衡性、日志i/o影响揭示系统协同状况；缓存命中率、上游健康度、流量特征匹配则锚定业务语义层指标。
要综合考量 Nginx 的运行效能，不能只看单一数字，得把连接状态、请求处理、资源消耗和业务表现这几块串起来看。核心是“连得上、接得住、转得快、撑得久”。
连接与并发能力
这是最基础的效能门槛。重点关注：
-
活跃连接数：通过
stub_status模块获取Active connections，它反映当前真实承载量；持续接近worker_connections × worker_processes上限，说明连接已逼近瓶颈。 -
握手与拒绝情况：
accepts（总接受连接）、handled（成功处理）、requests（总请求数）三者比值应接近 1:1:1；若handled ，可能因文件描述符不足或内存紧张被内核丢弃连接；<code>requests / handled远低于 10，说明长连接复用率低，频繁建连开销大。 -
连接分布：用
netstat -an | grep :80 | awk '{print $6}' | sort | uniq -c | sort -n查看连接状态（ESTABLISHED、TIME_WAIT 等），大量TIME_WAIT可能需调优内核参数（如net.ipv4.tcp_tw_reuse）。
请求处理效率
光连上不够，还得处理得快、稳：
-
响应时间分布：Nginx 日志中
$request_time是关键。不要只看平均值，重点看 P95/P99 延迟——若 P99 达到 2 秒但平均仅 200ms，说明少量请求严重拖慢，可能源于后端抖动或慢代理。 -
错误率分层定位：区分
4xx（客户端问题，如 499 表示客户端主动断开）、5xx（服务端问题，如 502/504 多为 upstream 超时或不可达）。突然升高的 504 往往指向 upstream 响应慢或超时设置过短。 -
请求复用率：检查日志中
$http_connection和$sent_http_connection，结合keepalive_requests配置，确认是否有效复用连接。静态资源场景下，单连接处理百次请求才算合理。
系统与 Nginx 资源协同
Nginx 不是孤岛，得看它和 OS 怎么配合：
-
文件描述符使用率：对比
worker_rlimit_nofile设置值与lsof -p $(cat /var/run/nginx.pid) | wc -l实际打开数。若长期超过 80%，需同步调高系统级限制（/etc/security/limits.conf）及内核fs.file-max。 -
CPU 与内存倾向：用
top -p $(pgrep nginx)观察 worker 进程 CPU 占用是否均衡（多核间差异大说明负载不均）；RSS 内存稳定增长且不释放，可能是缓存未配置淘汰策略或日志缓冲区过大。 -
磁盘 I/O 影响：开启 access_log 且写入高频时，
iotop可见 nginx worker 写日志阻塞。建议异步日志（access_log /path/log main buffer=64k flush=5s）或转至 syslog。
业务语义层指标
脱离业务谈性能是空谈：
-
缓存命中率：对静态资源或 proxy_cache 场景，加日志变量
$upstream_cache_status，统计HIT/MISS/EXPIRED比例。低于 70% 需检查缓存键设计、过期时间或后端响应头（如Cache-Control覆盖）。 -
上游健康度：若用
upstream，监控nginx_upstream_fails（Prometheus）或日志中的upstream_addr错误地址。某节点连续失败触发max_fails，会自动摘除，但需确认是否真故障还是临时抖动。 - 流量特征匹配：例如视频下载服务，应关注大 body_size 请求占比和带宽利用率；API 网关则更看重小包 QPS 和 TLS 握手耗时。指标权重必须按实际业务定。
