监控 brotli cpu 损耗需量化其在真实流量中对 cpu 时间的占用比例，通过系统观测、请求日志与压测对比交叉验证；重点抓取 $brotli_ratio、$request_length、$body_bytes_sent 等字段，结合 pidstat、perf 定位热点，并通过开关 brotli 的定向压测计算净开销，超 15%~20% 时应降级压缩等级或启用预压缩。
监控 Brotli 带来的 CPU 性能损耗，核心不是看“压缩是否发生”，而是量化它在真实流量下对 CPU 时间的占用比例。Nginx 本身不暴露压缩耗时或 CPU 占用毫秒级指标，需结合系统级观测、请求粒度日志与压测对比三方面交叉验证。
抓取关键日志字段，定位高开销请求
在 log_format 中加入能反映压缩强度和资源特征的变量，例如：
-
$brotli_ratio：值越大（如 >5），通常意味着原始内容冗余高、但压缩计算也更重；突然出现大量 ratio 极高（如 >8）且响应时间同步飙升的请求，很可能是 CPU 瓶颈源头 -
$request_length和$body_bytes_sent：小请求（ -
$upstream_response_time（若为动态后端）或$request_time：当$request_time显著高于$upstream_response_time，差值部分大概率就是 Nginx 自身压缩耗时
用系统工具绑定到 Nginx worker 进程观察 CPU 消耗
Brotli 压缩由 Nginx worker 进程同步执行，因此 CPU 开销直接体现在其进程上：
- 用
top -p $(pgrep -f "nginx: worker")实时观察各 worker 的 %CPU 占用，尤其关注是否出现单个 worker 持续 >80% 的情况 - 配合
pidstat -u -p $(pgrep -f "nginx: worker") 1，每秒采样，可看到压缩高峰时段的 CPU 使用毛刺 - 若使用
perf record -p $(pgrep -f "nginx: worker") -g -- sleep 30录制 30 秒，再用perf report查看热点函数，常会发现EncodeData或BrotliEncoderCompress占比异常高
做定向压测，分离压缩模块的 CPU 贡献
关闭 Brotli 后在同一环境复现相同请求流量，对比 CPU 指标变化，是最直接的归因方式：
- 先记录开启
brotli on时，在 QPS=500 场景下 5 分钟平均 CPU 使用率（如 42%） - 临时注释掉所有 brotli 指令，reload 配置，保持其他条件完全一致，再压测同样 QPS，记录新 CPU 使用率（如 28%）
- 差值（14%）即为当前负载下 Brotli 压缩带来的净 CPU 开销；若该值超过总 CPU 的 15%~20%，就应考虑降级压缩等级或启用预压缩
- 重点测试
brotli_comp_level从 6→4 或 4→2 时的 CPU 下降幅度——实测显示，level 4 到 level 2 往往能降低 40%+ 压缩 CPU，而压缩率仅损失 3%~5%
关联响应延迟，识别 TTFB 受损请求
CPU 瓶颈最直接影响首字节时间（TTFB），尤其对动态内容：
- 在 access_log 中加入
$request_time和$upstream_header_time（后端返回首字节时间） - 筛选出
$request_time - $upstream_header_time > 0.05（即 TTFB 比后端响应慢 50ms 以上）的请求，再按$brotli_ratio分组统计 - 若高 ratio 请求集中出现在高延迟样本中，说明 Brotli 正在拖慢首包——此时应优先对 HTML/JSON 类动态响应设
brotli_comp_level 1–3，而非统一用 6 或 11
