雷池社区版WAF性能测试教学文档

测试客户端(wrk/wrk2) → WAF(雷池) → 业务服务器(nginx返回200)

deploy:
  resources:
    limits:
      cpus: '1'

thread_num: 1  # 改为1减少context-switch

综合单核QPS = 1 / (1/QPS_tengine + 1/QPS_detector + 1/QPS_mario)

雷池社区版WAF性能测试教学文档 1. 背景介绍 长亭科技的雷池社区版WAF是国内WAF领域的佼佼者，其特点包括： 采用语义分析技术，检测准确性高且误报率低 社区版直接使用企业版检测引擎（可能不是最新版本） 相比其他开源WAF有明显优势 2. 测试环境配置 硬件配置 CPU: Intel i7-12700 内存: 64G DDR5 4800 内核版本: 5.17.15-051715-generic Docker版本: 20.10.21 软件版本 雷池社区版: 1.3.0 测试工具: wrk: 简单HTTP性能测试工具 wrk2: 支持固定QPS的wrk魔改版 3. 测试架构 4. 核心服务组件分析 雷池WAF包含三个关键服务： 4.1 safeline-tengine 基于阿里魔改版nginx的反向代理 负责接收请求并代理给业务服务器 4.2 safeline-detector 核心检测服务 进程名: snserver 多线程架构（默认线程数≈CPU核心数） 配置文件路径: /resources/detector/snserver.yml 4.3 safeline-mario 检测日志分析和持久化服务 高负载时内存占用会持续上升 5. 性能测试方法 5.1 测试指标 关注"单个服务仅分配且占满一个CPU核心时可支撑的QPS" 使用两种请求类型: 简单GET请求（无请求体） 带1K JSON body的GET请求 5.2 资源限制配置 在 compose.yml 中为服务添加资源限制: 6. 性能测试结果 6.1 简单GET请求测试 初始配置(多线程): detector瓶颈QPS: 4175 优化后(单线程): detector QPS: 17000+ mario成为新瓶颈（内存持续上升） 6.2 带1K body的复杂请求测试 detector单核极限QPS: ~10000 tengine单核极限QPS: ~28000 mario单核极限QPS: ~11000（需2核避免内存持续增长） 6.3 性能数据汇总表 | 服务组件 | 简单请求QPS | 复杂请求(1K body)QPS | |---------|------------|---------------------| | tengine | >28000 | ~28000 | | detector| ~17000 | ~10000 | | mario | <17000 | ~11000 | 7. 性能优化建议 7.1 线程数优化 detector默认线程数过多导致上下文切换开销 修改 snserver.yml 中的线程配置: 7.2 潜在优化点 detector多线程可能存在锁竞争，导致多核开销偏高 mario高负载时内存持续升高，有OOM风险 各组件资源分配需要平衡 8. 部署建议 8.1 资源规划公式 8.2 实际部署考虑 根据预期流量计算所需CPU核心数 特别注意mario组件的内存需求 复杂请求场景下detector会成为主要瓶颈 9. 测试结论 对于简单请求，detector单核可处理~17000 QPS 对于带1K body的请求，detector单核可处理~10000 QPS mario在高QPS下会成为瓶颈，且内存占用会持续增长 实际部署需根据业务流量特征进行针对性调优 附录：关键配置文件位置 detector配置: /resources/detector/snserver.yml mario配置: 安装目录下的对应配置文件 docker compose配置: /data/safeline/compose.yml 注意：所有配置修改后需执行 docker compose up -d 重启服务生效。