最有效的方式是直接压测对比，重点观察开启open_file_cache后系统调用openat/statx次数是否下降60%以上、%system CPU占比显著降低、await减少20%~50%，且命中率可监控。
直接压测对比是最有效的方式。关键不是看“有没有缓存”，而是看开启 open_file_cache 后，系统层面的 open()、stat() 系统调用次数是否明显下降，以及 CPU 和 I/O 等待时间是否同步降低。
准备两个可对比的 Nginx 配置环境
搭建两套完全一致的 Nginx 服务（相同版本、相同静态文件集、相同硬件），仅区别在 open_file_cache 开关：
- 环境 A：关闭缓存 —— 配置中明确写
open_file_cache off; - 环境 B：开启缓存 —— 配置如：
open_file_cache max=2048 inactive=60s; open_file_cache_valid 30s; open_file_cache_min_uses 2; open_file_cache_errors on; - 确保其他影响 I/O 的配置一致：比如
sendfile on、tcp_nopush on、access_log off（避免日志干扰）
用工具抓取核心系统指标
不要只看 Nginx 自带的 nginx_status，它不反映底层系统调用。重点监控以下三项：
-
系统调用频次：用
perf stat -e 'syscalls:sys_enter_openat,syscalls:sys_enter_statx' -p $(pgrep nginx)或bpftrace脚本统计单位时间内openat和statx调用次数 -
CPU 负载分布：用
pidstat -u -p $(pgrep nginx) 1观察 %system（内核态 CPU 占比），缓存生效后该值应显著下降 -
I/O 等待：用
iostat -x 1查看%util和await，尤其在高并发静态请求下，开启缓存后磁盘响应延迟通常降低 20%~50%
设计有区分度的压测场景
单一 URL 循环请求会掩盖问题，要模拟真实访问模式：
- 用
wrk或ab发起 100–500 并发，持续 2 分钟，路径列表包含 100+ 个不同静态文件（如/img/1.jpg到/css/v2.3.css） - 加入“热点+冷门”混合：让其中 20% 文件被反复访问（测试缓存复用），其余 80% 只访问一次（测试缓存淘汰与错误缓存效果）
- 特别加一组“不存在路径”压测（如
/nonexistent/xxx.js），验证open_file_cache_errors on是否真能减少无效stat调用
观察与判断优化是否生效
真正有效的缓存优化，会在数据上呈现一致性变化：
- 环境 B 的
openat调用数应比环境 A 低 60% 以上（尤其在请求量 > 缓存容量后仍保持稳定） - 环境 B 的
%systemCPU 占比下降明显，而%user基本不变，说明节省的是内核开销 - 如果
await下降但%util不变，说明是减少了小文件随机 I/O；如果两者都降，说明整体磁盘压力减轻 - 注意检查
open_file_cache命中率：可通过nginx -V 2>&1 | grep -o with-http_stub_status_module确认模块已编译，再配合自定义日志或 Prometheus + nginx-vts-exporter 抓取缓存状态指标
