性能取决于开了多少功能
WAF 的容量不是一个固定数字：规则数量、是否检测请求体、是否做 TLS 解密、是否启用挑战，都会明显改变单个请求的处理成本。选型与容量评估必须按「全功能开启」后的真实情况来算，只看静态页面转发能力必然高估。
按峰值规划并留余量
业务峰值往往是日常的数倍：活动、大促、集中导出都会把请求数推高。评估时按历史峰值的上沿确定规格并留出余量，用于应对突发流量和后续规则增长，否则第一次大促就变成了对设备的压力测试。
基本信息
| 关键指标 | QPS、并发连接数、响应时延增量、CPU 与内存 |
|---|---|
| 影响项 | 规则数量、请求体检测、TLS 解密、人机验证 |
| 监控要求 | 设备资源与业务响应时间同时监控 |
| 评估顺序 | 先采集峰值曲线，再按全功能状态核对规格 |
典型使用场景
- WAF 选型与规格确认
- 大促或活动前的容量复核
- 新增 TLS 解密或规则组前评估影响
- 上线后出现响应变慢，判断是否为设备瓶颈
- 压测方案设计：覆盖高成本接口
- 容量告警阈值设定
评估步骤
评估步骤
# 1. 采集工作日与高峰期的 QPS 与并发连接曲线
# 2. 按全功能开启状态核对设备规格（含解密与请求体检测）
# 3. 压测验证时延与稳定性，覆盖上传、导出等高成本请求
# 4. 预留三成以上余量，用于突发流量与规则增长
# 5. 上线后监控设备资源与业务响应时间，建立基线影响项与成本
| 影响项 | 成本特点 |
|---|---|
| 规则数量 | 规则越多，单请求匹配开销越大 |
| 请求体检测 | 大文件上传与导出场景开销明显 |
| TLS 解密 | 加解密消耗 CPU，叠加检测后成本更高 |
| 人机验证 | 挑战触发频繁时对交互与后端都有压力 |
活动类业务的峰值可能是日常的数倍，容量评估必须按峰值而不是平均值来做。
只测静态页面会严重低估成本：上传、导出、下载这类大请求体的接口，才是真正吃资源的地方。
把设备资源与业务响应时间放在同一张趋势图上：只看设备 CPU 无法判断用户是否已经感受到变慢。