验证 proxy_cache levels 参数是否提升文件系统访问效率，需检查多级目录结构、高并发下响应表现、I/O 分布及 inode 使用，并通过 strace、wrk 和哈希分布分析综合评估。
测试 proxy_cache 缓存目录的分级存储性能，核心是验证 levels 参数是否真正提升了文件系统访问效率，避免单目录海量文件导致的 inode 查找延迟。不能只看“有没有生成多级目录”，而要看高并发写入/读取时的响应表现和磁盘 I/O 分布。
检查目录结构是否按预期生成
进入 proxy_cache_path 指定的根路径（如 /var/cache/nginx），执行：
-
find . -maxdepth 3 -type d | head -20—— 确认存在类似./a/1f/、./7/b3/的两级子目录结构 -
find . -maxdepth 3 -type f | wc -l—— 统计当前缓存文件总数，若超 5 万，单级目录已明显不适用 - 对比
levels=1:2和levels=2:2:2下同一压测量级的子目录数量：find . -mindepth 2 -maxdepth 2 -type d | wc -l
用 strace 观察单次缓存查找的系统调用开销
挑一个已缓存的请求（确保返回 X-Cache-Status: HIT），对 Nginx worker 进程做轻量级追踪：
aperture: the L402 aware reverse proxy
下载
安装并运行 Aperture（Lightning Labs 的 L402 闪电反向代理），用于创建 L402 付费墙、配置付费 API 端点、为其他代理托管付费内容或测试 L402 认证流程。
strace -p $(pgrep -f "worker process" | head -1) -e trace=openat,stat,fstat -T 2>&1 | grep -E "(cache|\.tmp)"- 观察
openat调用耗时（<...> = 0.000012</...>表示微秒级）；若频繁出现 >100μs 的stat或目录遍历，说明层级过浅或哈希冲突高 - 注意是否出现大量
openat(AT_FDCWD, "/var/cache/nginx/...", ...)走同一父目录——这暴露了levels设计不合理
压测对比不同 levels 下的缓存吞吐与延迟
使用 wrk 对同一缓存 URL 发起 200 并发、持续 60 秒压测，分别配置 levels=1:2 和 levels=2:2:2，记录关键指标：
- Nginx access log 中每秒
$upstream_cache_status为HIT的请求数（应稳定在高位） -
iostat -x 1观察%util和await：分级合理时，await应低于 3ms，且%util分布更均匀 - 对比
cat /proc/sys/fs/inode-nr中第二列（已分配 inode 数）增长速率 —— 分级差的配置会更快耗尽单目录 inode
验证缓存键哈希分布是否均衡
随机采样 1 万次缓存 key（可从日志提取 $request_uri 或自定义 proxy_cache_key），计算 MD5 后 3 位，并统计前缀分布：
-
awk '{print $7}' /var/log/nginx/access.log | md5sum | cut -c1 | sort | uniq -c（粗略看首位是否均匀） - 更准确方式：用 Python 脚本模拟 Nginx 哈希逻辑（取 MD5 后 3 字符），检查 16×256=4096 个二级目录中，空目录数是否
- 若发现某一级目录（如
/0/）下文件占比超 40%，说明 key 设计有偏（如大量请求带相同 query 参数），需优化proxy_cache_key
