Nginx 中 Brotli 压缩如何评估高并发场景下 Brotli 对 CPU 资源的额外占用率

Brotli 本身不必然导致 CPU 过载，关键在配置失当：高频小响应、大体积动态响应、高压缩级别滥用三类行为会使其成为“CPU 放大器”；应结合日志分析、降级验证与预压缩优化。

评估高并发下 Brotli 对 CPU 的额外占用，关键不是看“开了 Brotli 之后 CPU 升了多少”，而是看压缩行为是否在错误时机、对错误资源、以错误强度被触发。Brotli 本身不必然导致 CPU 过载，但配置失当会让它在流量高峰时变成“CPU 放大器”。

盯住三类高危压缩行为

真正吃 CPU 的从来不是 Brotli 算法本身，而是它被反复、低效、无差别调用的过程：

1. 高频小响应压缩：brotli_min_length 过低（如默认 20 字节），导致大量 API 空响应、短 JSON、304 响应反复进压缩流程，徒增事件循环负担
2. 大体积动态响应压缩：brotli_types 包含 application/json 或 text/html，而上游返回未分块的 3MB+ HTML/JSON，Brotli 会全量缓冲再压，内存+CPU 双飙升
3. 高压缩级别滥用：brotli_comp_level 设为 9 或 11，实测 Level 6 到 Level 11 的 CPU 耗时常呈指数增长，但体积仅多减 2%–3%

用真实请求特征反推 CPU 压力源

别只看 top 里 nginx worker 的 %CPU，要结合 access log 和 error log 找出“谁在拖慢整体”：

1. 在 access log 中加入 $sent_http_content_encoding $request_time $body_bytes_sent $http_user_agent 字段，采样高峰期数据
2. 筛选出 content-encoding: br 且 $body_bytes_sent > 500000（500KB+）或 $request_time > 0.5（500ms+）的请求，它们大概率是 CPU 热点
3. 同步检查 error.log 是否出现 pool alloc 频繁记录、worker process X exited on signal 9 或 upstream timeout —— 这些是内存和 CPU 同时承压的信号

做一次轻量级降级验证

这是归因最直接的方法，无需改代码或重编译：

1. 临时注释掉所有 brotli_* 指令（保留 gzip off），reload Nginx
2. 观察 5–10 分钟内 CPU 使用率变化（建议用 htop 看单个 worker 进程，而非整体平均）
3. 若 CPU 显著回落（如从 85% → 45%），且 TTFB 下降明显，说明 Brotli 配置确为瓶颈；若变化微弱，则问题可能在 rewrite、SSL 握手或后端延迟

用预压缩替代动态压缩来卸载 CPU

对 JS/CSS/HTML/SVG 等静态资源，完全可绕过运行时压缩：

1. 构建阶段用 brotli -Z -f --quality=11 asset.js 生成 asset.js.br
2. Nginx 开启 brotli_static on;，并确保 brotli on; 仍启用（兜底用）
3. 此时 Brotli 不再消耗 CPU，仅多一次文件存在性判断（stat 系统调用），开销可忽略