WAF 的性能为何敏感
WAF 通常串联在业务链路里，每个请求都要经过它解密、解析、匹配规则，然后才到后端。这意味着 WAF 的时延与处理能力直接构成用户体验的一部分。规则集越全、检测越深，开销越大；大促前后流量成倍增长时，性能余量决定了是否会成为瓶颈。建立基线的作用是：当业务反馈变慢时，能判断这是不是 WAF 引入的，而不是各方凭体感互相推责。
基本信息
| 核心指标 | 请求吞吐（QPS）、平均时延与尾部时延、并发连接数、CPU 与内存 |
|---|---|
| 采集方式 | WAF 自带监控、上游负载均衡统计、应用侧埋点三方对照 |
| 对照口径 | 业务高峰与低谷分别采集，按周取样本形成趋势 |
| 变更场景 | 规则集升级、防护模式切换、新业务上线前后都要重新采样 |
| 压测限制 | 压测只在测试环境进行，生产环境压测需另行审批 |
典型使用场景
- 大促、开学季、活动上线前的容量评估：确认 WAF 在预估流量下仍有余量
- 规则集升级后业务变慢：用基线判断新增检测规则带来的时延增量
- SSL 卸载开启或关闭的性能差异评估，尤其是加解密开销
- 排查用户反馈的偶发慢请求，区分是尾部时延问题还是后端本身慢
- 为多台 WAF 节点做健康对比，发现某台节点性能异常偏离
- 向上汇报容量规划依据，把扩容需求建立在数据上而不是直觉上
性能对比流程
性能对比流程
1. 变更前采集基线：QPS、平均时延、P95/P99 时延、CPU # 记录高峰与低谷两个时段
2. 记录当时的规则库版本与防护模式 # 否则对比条件不成立
3. 执行变更（规则升级、模式切换、上线新业务）
4. 同条件再采一次，对比各项指标的偏差幅度
5. 偏差超出预期时回退或调优，并记录结论指标逐列读法
| 指标 | 含义 | 观察重点 |
|---|---|---|
| 吞吐 QPS | 单位时间内 WAF 处理的请求数 | 与峰值业务量对比，判断余量与瓶颈位置 |
| 平均时延 | 请求经过 WAF 的平均处理耗时 | 关注变更前后的增量，而非绝对值大小 |
| 尾部时延 | P95/P99 分位的请求耗时 | 少量慢请求常被平均值掩盖，用户体验更受尾部分布影响 |
| 并发连接 | 同时保持的连接数 | 接近设备上限时新连接排队，表现为整体变慢 |
| CPU 占用 | 检测与加解密线程的处理器消耗 | 持续高位说明规则或流量已超出当前规格的舒适区 |
没有基线的性能讨论最容易变成互相猜疑：业务说安全拖慢了，安全说后端本身慢。把变更前的数字留档，是最省事的自证方式。
生产环境直接做压测属于高风险动作：可能被误判为攻击并触发封禁，也会影响真实用户。容量验证放在测试环境，生产只做真实流量的长期观察。