WarpParse、Vector、Logstash 性能基准测试报告

1. 技术概述与测试背景

1.1 测试背景

本报告记录在 Mac 平台完成的单机基准测试结果，覆盖从轻量级 Web 日志到复杂安全威胁日志的典型场景，用于形成阶段性 benchmark 基线，便于后续版本或方案之间的横向与纵向对比。本文仅描述测试方法与结果，不对生产环境性能上限作外推。

1.2 被测对象

• WarpParse: 大禹安全公司研发的 ETL 核心引擎，采用 Rust 构建。
• Vector: 开源可观测性数据管道工具，采用 Rust 构建。
  • Vector-VRL：基于 VRL 的 parse_regex(Firewall 使用 KV 解析；APT 仍使用正则解析) 进行正则解析。
  • Vector-Fixed：优先使用内置解析（如 nginx/aws 内置函数）。
• Logstash: Elastic 生态的日志处理引擎，采用 JVM 运行时。

1.3 测试对象与版本说明

本次测试使用版本如下：

• WarpParse：0.12.0
• Vector：0.49.0
• Logstash：9.2.3

构建与来源信息：

• WarpParse：构建来源/commit/tag = GitHub tag v0.12.0-alpha (commit: 2ba6e55)；构建参数 = 官方 release 构建产物（zip/tar.gz），未修改构建选项
• Vector：构建来源/commit/tag = v0.49.0 (commit: dc7e792)；构建参数 = 官方发布的 release 二进制，未修改构建选项
• Logstash：构建来源/commit/tag = GitHub tag v9.2.3 (commit: 4eb0f3f)；构建参数 = 官方发行包（zip / tar.gz，bundled JDK），未进行源码级构建

本报告已记录版本与构建来源；复现时仍需确保引擎运行参数、系统配置与数据集参数一致。

1.4 报告定位

本文档定位为阶段性 benchmark 报告，侧重方法与数据的可复现性与长期可比性，不作为最终性能结论或生产容量承诺。

2. 测试环境与方法

2.1 测试环境（Test Environment）

平台信息（Platform）

• 平台类型：Mac mini（Apple M4）
• 操作系统：macOS 15.5
• 系统架构：arm64
• 网络环境：本机回环（127.0.0.1）

计算资源（Compute）

• CPU：10-core
• 内存：16 GiB
• 后台任务/性能模式：测试期间关闭不必要后台任务；未做额外系统调优

存储配置（Storage）

• 存储介质：Internal SSD
• 文件系统：APFS
• 卷大小：256G

2.2 测试范畴 (Scope)

• 日志类型:
  • Nginx Access Log (239B): 典型 Web 访问日志，高吞吐场景。
  • AWS ELB Log (411B): 云设施负载均衡日志，中等复杂度。
  • Firewall Log (1K): 终端安全监控日志，JSON 结构，字段较多。
  • APT Threat Log (3K): 模拟的高级持续性威胁日志，大体积、长文本。
  • Mixed Log (886B): 上述四类日志混合起来形成的日志类型。
• 数据拓扑:
  • File -> BlackHole: 测算引擎极限 I/O 读取与处理能力 (基准)。
  • TCP -> BlackHole: 测算网络接收与处理能力。
  • TCP -> File: 测算端到端完整落地能力。
• 测试能力:
  • 解析 (Parse): 仅进行正则提取/KV解析与字段标准化。
  • 解析+转换 (Parse+Transform): 在解析基础上增加字段映射、富化、类型转换等逻辑。

2.3 评估指标

• EPS (Events Per Second): 每秒处理事件数（核心吞吐指标）。
• MPS (MiB/s): 每秒处理数据量。
• CPU (Avg/Peak): 测试进程 CPU 使用率的平均值与峰值。
• MEM (Avg/Peak): 测试进程内存占用的平均值与峰值。
• Rule Size: 规则配置文件体积，用于衡量在表达同等日志语义时所需的描述复杂度，同时辅助评估配置分发、可读性与长期维护成本。
• 性能倍数: 在同一日志类型 + 同一拓扑下，以 Vector-VRL 的 EPS 为 1.0x 进行归一化。

说明：

• CPU 为多核累计百分比（例如 800% ≈ 8 个逻辑核满载），统计对象为测试进程本身（非系统总 CPU），由外部监控脚本按固定采样周期采集并计算 Avg/Peak。
• MPS 换算公式：MPS = EPS × AvgLogSize(B) / 1024 / 1024。

• 采样来源与采样口径说明：
  • EPS：统一基于各引擎原生可观测性或统计接口获取。
    • WarpParse / Vector：使用引擎内置的吞吐统计能力。
    • Logstash：通过自动化脚本定期采集其官方 Monitoring API / 运行时统计信息。
  • CPU / MEM：通过外部监控脚本采集测试进程的资源使用情况（基于 shell 的周期性采样），用于跨引擎对比。
  • MPS：基于测得的 EPS 与对应日志的平均大小进行换算计算，用于辅助衡量实际数据吞吐规模。
  • 规则大小统计前对配置进行了统一去注释/去空行处理，仅保留有效表达部分，降低格式差异影响。
  • 各指标在不同引擎中的采集实现方式可能不同，但统计口径保持一致，结果以各指标最权威来源为准。

2.4 测试方法与执行方式

测试在单机环境中按日志类型与拓扑逐项执行。输入数据由本仓库提供的 benchmark 脚本生成或回放， 测试过程中各引擎独立运行，避免相互干扰。 输出目标根据测试拓扑配置为 BlackHole 或 File，以分别评估纯处理能力与包含 I/O 的端到端性能。

测试执行流程、脚本入口及通用参数说明见 benchmark/README.md。

2.4.1 最小复现清单（Minimal Repro Checklist）

• 引擎版本与来源：

  • WarpParse / Vector / Logstash 的版本、tag、commit 及构建方式见 1.3。

• Benchmark 工具链版本：

  • benchmark 仓库以 wp-example 仓库的最新提交（repo HEAD）为准。
  • 复现实验时建议记录具体 commit hash 以保证结果可追溯。

• 数据规模与事件数量：

  • 本报告中“数据集规模”与“事件数量”为同一概念，均以处理的事件总数作为规模定义。
  • 在 WarpParse 的 benchmark 执行脚本中，通过参数 -c 指定事件总数； 该参数用于明确数据集规模，但并非要求所有引擎具备相同参数形式。
  • 对于 Vector 与 Logstash，测试数据集规模与 WarpParse 使用相同的事件数量， 通过等量输入数据实现规模对齐，而非依赖统一的启动参数。
  • 因此，-c 可视为本 benchmark 中“统一事件规模定义”的符号化表示， 而非跨引擎通用的命令行参数。

• 结束条件：

  • 所有测试均以处理完成等量事件作为结束条件。
  • 不采用按固定运行时长结束的方式， 以避免不同引擎在启动、预热与稳定阶段差异带来的统计偏差。

• Warmup 与采样窗口：

  • WarpParse 与 Vector：引擎启动后快速进入稳定状态，未单独区分 warmup 阶段。

  • Logstash：由于 JVM/JIT 与 pipeline 初始化特性，测试前先进行 warmup 运行； 在确认吞吐进入稳定区间后，开始采集 EPS / 资源指标。

  • 重复次数与取值规则：

    • 默认单次运行。
    • 如需更严格统计，建议重复 N=3 次并取 median 作为最终结果。

2.5 默认配置与调优说明

除非表格或备注中明确说明，本报告结果基于各引擎默认配置，未开启专项性能调优或非默认参数。

3. 详细性能对比分析

3.0 测试结果汇总表

下表为结果索引，用于定位不同日志类型与测试能力的明细表格。

3.1 日志解析能力 (Parse Only)

本节给出纯解析场景的测试结果。

3.1.1 Nginx Access Log (239B)

表 3.1.1-1：Nginx Access Log（Parse Only；File -> BlackHole / TCP -> BlackHole / TCP -> File）

解析规则大小：

• WarpParse：150B
• Vector-VRL：217B
• Vector-Fixed：86B
• Logstash：248B

在同一日志类型 + 同一拓扑下，以 Vector-VRL 的 EPS 作为统一基准（1.0x），对所有引擎进行归一化对比。

3.1.2 AWS ELB Log (411B)

表 3.1.2-1：AWS ELB Log（Parse Only；File -> BlackHole / TCP -> BlackHole / TCP -> File）

解析规则大小：

• WarpParse：1153B
• Vector-VRL：921B
• Vector-Fixed：64B
• Logstash：876B

在同一日志类型 + 同一拓扑下，以 Vector-VRL 的 EPS 作为统一基准（1.0x），对所有引擎进行归一化对比。

3.1.3 Firewall Log (1K)

表 3.1.3-1： Firewall Log（Parse Only；File -> BlackHole / TCP -> BlackHole / TCP -> File）

解析规则大小：

• WarpParse：137B
• Vector-VRL：317B
• Logstash：527B

在同一日志类型 + 同一拓扑下，以 Vector-VRL的 EPS 作为统一基准（1.0x），对所有引擎进行归一化对比。

3.1.4 APT Threat Log (3K)

表 3.1.4-1：APT Threat Log（Parse Only；File -> BlackHole / TCP -> BlackHole / TCP -> File）

解析规则大小：

• WarpParse：985B
• Vector：873B
• Logstash：1027B

在同一日志类型 + 同一拓扑下，以 Vector-VRL的 EPS 作为统一基准（1.0x），对所有引擎进行归一化对比。

3.1.5 Mixed Log (平均日志大小：886B)

表 3.1.5-1：Mixed Log（Parse Only；File -> BlackHole / TCP -> BlackHole / TCP -> File）

解析规则大小：

• WarpParse：3864B
• Vector-VRL：4723B
• Vector-Fixed：1733B
• Logstash：3984B

在同一日志类型 + 同一拓扑下，以 Vector-VRL 的 EPS 作为统一基准（1.0x），对所有引擎进行归一化对比。

混合日志规则：

• 4类日志按照3:2:1:1混合

3.1.6 Mixed Log (平均日志大小：867B)

表 3.1.6-1：Mixed Log（Parse Only； TCP -> BlackHole ）

• 20000EPS下的资源消耗情况
• logstash在warmup后采集

3.2 解析 + 转换能力 (Parse + Transform)

本节给出解析 + 转换场景的测试结果。

3.2.1 Nginx Access Log（239B）

表 3.2.1-1：Nginx Access Log（Parse + Transform；File -> BlackHole / TCP -> BlackHole / TCP -> File）

解析+转换规则大小：

• WarpParse：521B
• Vector-VRL：519B
• Vector-Fixed：500B
• Logstash：712B

在同一日志类型 + 同一拓扑下，以 Vector-VRL 的 EPS 作为统一基准（1.0x），对所有引擎进行归一化对比。

3.2.2 AWS ELB Log（411B）

表 3.2.2-1：AWS ELB Log（Parse + Transform；File -> BlackHole / TCP -> BlackHole / TCP -> File）

解析+转换规则大小：

• WarpParse：1694B
• Vector-VRL：1259B
• Vector-Fixed：570B
• Logstash：2019B

在同一日志类型 + 同一拓扑下，以 Vector-VRL 的 EPS 作为统一基准（1.0x），对所有引擎进行归一化对比。

3.2.3 Firewall Log (1K)

表 3.2.3-1：Firewall Log（Parse Only；File -> BlackHole / TCP -> BlackHole / TCP -> File）

解析规则大小：

• WarpParse：2249B
• Vector-VRL：2344B
• Logstash：3453B

在同一日志类型 + 同一拓扑下，以 Vector-VRL的 EPS 作为统一基准（1.0x），对所有引擎进行归一化对比。

3.2.4 APT Threat Log (3K)

表 3.2.4-1：APT Threat Log（Parse + Transform；File -> BlackHole / TCP -> BlackHole / TCP -> File）

解析+转换规则大小：

• WarpParse：1638B
• Vector-VRL：1382B
• Logstash：2041B

在同一日志类型 + 同一拓扑下，以 Vector-VRL的 EPS 作为统一基准（1.0x），对所有引擎进行归一化对比。

3.2.5 Mixed Log (平均日志大小：886B)

表 3.2.5-1：Mixed Log（Parse + Transform；File -> BlackHole / TCP -> BlackHole / TCP -> File）

解析+转换规则大小：

• WarpParse：3864B
• Vector-VRL：4723B
• Vector-Fixed：1733B
• Logstash：3984B

在同一日志类型 + 同一拓扑下，以 Vector-VRL 的 EPS 作为统一基准（1.0x），对所有引擎进行归一化对比。

规则大小可能受格式/换行/注释/路径等影响，体积差异不影响性能口径；规则逻辑保持一致。

混合日志规则：

• 4类日志按照3:2:1:1混合

3.2.6 Mixed Log (平均日志大小：867B)

表 3.2.6-1：Mixed Log（Parse Only； TCP -> BlackHole ）

• 20000EPS下的资源消耗情况
• logstash在warmup后采集

4. 结果解读

4.1 吞吐与资源表现

结果摘要:

1. 在 Mac 平台测试中，WarpParse 相对 Vector-VRL 的 EPS 倍数范围为：解析 1.42x - 8.78x，解析+转换 1.35x - 8.44x；峰值出现在 Nginx 的 TCP -> File 拓扑。
2. 在同等事件量下，WarpParse 场景的 CPU 使用率整体高于 Vector/Logstash（见各表）；吞吐提升与 CPU 占用同时出现。
3. APT (3K) 场景下，WarpParse 的 MPS 最高为 1109.53 MiB/s（File -> BlackHole）；Vector 在同场景的 EPS/MPS 相对更低（见 3.1.4/3.2.4）。

4.2 规则与表达能力要点

• 规则体积不仅反映配置分发与维护成本， 也可作为衡量引擎在表达同等日志语义时所需复杂度的参考指标。 在相同解析与转换语义下，规则体积越小，通常意味着引擎具备更高层级的内置能力或更强的表达抽象。

• 各日志类型与拓扑下的规则体积差异见对应表格“规则大小”备注， 用于辅助评估不同引擎在表达能力、规则可读性与维护复杂度方面的差异。

• Vector 测试同时包含 VRL 与 Fixed 两种策略：

  • VRL 更偏向通用表达能力，对复杂语义具备更强灵活性；
  • Fixed 优先使用内置解析能力，在规则体积与维护复杂度上更具优势。 两者在表达能力与性能上的权衡以表格数据为准。

• 在多数日志类型下，TCP → File 拓扑呈现更高的性能倍数区间（见 3.1 / 3.2 对应表格）， 该结论在不同规则复杂度水平下均保持一致。

4.3 稳定性

• 本报告未引入背压/队列深度等专用指标，稳定性判断仅基于运行期间吞吐与资源观测。
• 注意点: TCP -> File 大包场景下内存随吞吐上升（APT 场景峰值约 508 MB；Mixed 约 493 MB），需结合容量规划。

5. 阶段性总结与建议

以下为基于本报告范围的阶段性观察，不构成生产选型结论；实际落地需结合业务流量、架构约束与运维能力评估。

阶段性结论: 基于本报告数据，WarpParse 与 Vector-VRL 的 EPS 倍数区间为：纯解析 1.42x-8.78x，解析+转换 1.35x-8.44x，端到端（TCP -> File）倍数更高。上述结果可作为同类场景的阶段性基线参考；在大包 TCP -> File 场景需关注内存随吞吐上升（约 490-510MB）。

6. 已知限制与注意事项

• 本报告为单机测试，未覆盖多节点、HA（High Availability，高可用）、持久化优化或生产负载波动等因素。
• 测试范围限定为五类日志与三种拓扑，未覆盖更复杂的输入/输出链路。
• 结果依赖具体硬件、操作系统与存储配置，跨环境对比需谨慎。