Benchmark 方法：当前仓库里的正确打开方式

先避免一个常见误区

当前仓库有 benchmark 脚本，但这并不意味着我们已经拥有一套"可外推到任何机器"的性能实验体系。

更准确的理解是：

• 仓库提供了可重复的本地对比工具
• 可以做趋势分析、回归检测和参数扫描
• 更适合把单次结果当作具体场景下的观测样本

当前主要脚本

和 benchmark 直接相关的脚本主要有：

• script/compare_bench.sh
• script/bench_soak.sh

以及文档：

• doc/benchmark-results-2026-04-26.md
• doc/performance-analysis-2026-04-26.md

当前最可靠的测试方式

如果目标是回答"改动前后有没有退化"，最可靠的做法是：

Rendering diagram...

1. 固定测试机器
2. 固定参数
3. 连续多轮执行
4. 记录均值、最小值、最大值、P95/P99
5. 只比较同类场景

这也是 bench_soak.sh 采用的思路。

为什么不能拍脑袋设目标表

旧文章里常出现这样的表述：

• 吞吐应该大于 1M msg/s
• P99 应该小于 50us
• CPU 应该低于 80%

这些目标值在当前仓库里没有统一依据。不同脚本、payload、ack 模式、shards 和是否启用 checkpoint，都会显著改变结果。

因此博客更应该写"如何测"和"如何比"，而不是先写一组脱离上下文的 KPI。

当前推荐的基线方式

1. 单次对比

使用 compare_bench.sh 得到一次同机对比：

• log_engine
• glog
• spdlog

它适合快速看当前功能路径下三者的大致差异。

2. 长时间重复

使用 bench_soak.sh 在固定时长内循环执行同一场景，输出：

• TSV 原始结果
• Markdown 摘要

这更适合看：

• 吞吐波动
• P99 漂移
• 最差轮次是否异常

当前仓库里已经有的结果

截至 2026-04-26 的现有文档，最明确的一组结果是：

• log_engine_bench: 387732.15 msg/s
• glog_bench: 648441 msg/s
• spdlog_bench: 1024460 msg/s

这组数字只能说明那个具体场景下：

• 当前 log_engine 低于 glog/spdlog
• 功能路径更重的代价已经体现出来

不能说明：

• log_engine 的长期上限就是这个值
• 优化后一定能到某个更高档位

当前该怎么设计测试矩阵

如果要继续做工程化 benchmark，优先建议围绕这些真实参数维度：

Rendering diagram...

这些都是当前脚本或可执行程序已经支持的维度。

当前不该继续出现的内容

以下内容如果没有新增仓库证据，不建议继续出现在博客里：

• 固定硬件规格表
• 系统调优 checklist 被写成仓库既定标准
• 虚构的回归脚本和热力图结果
• 一套完整的"优化前后从 38 万到 150 万"的数字故事

这类内容的问题不是"想法错"，而是"当前仓库无法证明它已经发生"。

更实际的写法

如果你现在要写 benchmark 方法论，最好的切入点其实是：

• 哪些脚本已经存在
• 它们各自测什么
• 哪些指标会被输出
• 哪些比较是公平的，哪些不是

这比堆一堆看起来专业、但没有仓库支撑的测试学术模板更有价值。

结论

当前 seastar-log-engine 的 benchmark 方法更适合被描述为：

• 面向同机回归和参数比较的工程脚本集合
• 重点看趋势、波动和功能路径成本
• 暂时更适合围绕回归、趋势和参数差异来组织结论

方法论文章只要把这个边界写清楚，就已经比大多数"数字很多但来源不明"的性能文章更可靠。