如何解读 SurrealDB PR 上 crud-bench 基准的吞吐与 P50/P95/P99 延迟结果【免费下载链接】surrealdbA scalable, distributed, collaborative, document-graph database, for the realtime web项目地址: https://gitcode.com/GitHub_Trending/su/surrealdbSurrealDB 仓库有一个名为Performance Benchmarks的 CI 工作流.github/workflows/crud-bench.yml它在 PR 上用 crud-bench 工具跑 CRUD 基准测试完成后把结果以一条## CRUD Benchmark Results注释发布到 PR 上供人工 review 和对比。当你提交了涉及存储、查询或执行路径的改动后就需要靠这条注释判断性能是否回退。本文聚焦一件事拿到这条注释后如何读懂其中的吞吐ops/s与 P50/P95/P99 延迟以及如何区分真实回归与 CI 噪声。你不需要本地环境——基准全部在 CI 上运行产出形式是 PR 注释和 Actions artifacts。完整设计说明见 doc/BENCHMARKING.md。先弄清注释里的数字是怎么跑出来的解读结果前必须先知道测量口径否则表格里的数字无法对比工具版本固定。工作流通过CRUD_BENCH_REVISION环境变量锁定 crud-bench 的 git 版本见 crud-bench.yml 的env段所有 PR 使用同一工具版本避免工具自身变化被误判为性能回归。因此同一工具版本下的历史结果可以跨时间对比升级工具后新旧版本之间的历史对比不再可比。6 种配置 × 4 种键类型 24 个并行 job。每个 job 都从干净的数据库状态开始数据不跨 job 携带。6 种配置及其在 run-benchmark 动作中的参数如下配置crud-bench 数据库标识endpoint模式memorysurrealdb-memoryws://localhost:8000网络PR 编译出的 server 二进制rocksdbsurrealdb-rocksdbws://localhost:8000网络PR 编译出的 server 二进制embedded-memorysurrealdbmemory内嵌Cargo patch 链接 PR 的 SDKembedded-rocksdbsurrealdbrocksdb:~/crud-bench-data内嵌Cargo patch 链接 PR 的 SDKsurrealkv-localsurrealkv无本地存储引擎surrealmxsurrealmx无本地存储引擎网络配置测的是你的 PR 编译出的 server 二进制内嵌配置通过 Cargo patching 让 crud-bench 链接你 PR 里的 SDK 代码。也就是说所有 24 个 job 测的都是你 PR 的代码。4 种键类型integer、string26、string90、string250用于在不同索引场景小整数 vs 长字符串下测量性能。每个配置测量 4 类操作Create插入唯一记录、Read按主键 Select、Update修改已有记录、Delete删除记录。并发参数12 个并发客户端、每客户端 48 线程、随机化键生成-r标志。网络配置的服务器启动方式action.ymlsurreal start --log error --user root --pass root memory或rocksdb:~/surrealdb-data启动后轮询http://localhost:8000/health确认就绪最多等 30 秒。一处需要注意的文档冲突doc/BENCHMARKING.md 与分析脚本的 Methodology 文案都写样本量为 10,000但当前工作流实际传参是-s 100000action.yml。判断某次运行用了什么参数以该次运行对应的工作流文件为准。报告的结构PR 注释、明细区与 artifacts基准完成后analyze-and-reportjob 用 Python 脚本 .github/scripts/analyze_benchmark.py 合并 24 个 job 的 JSON 结果生成报告并发布/更新 PR 注释。注释包含三部分Summary Table按配置分组的汇总表表头固定为Key TypeOperationThroughputP50P95P99每个配置一张表表内按键类型integer、string26、string90、string250顺序排列每个键类型下是 Create / Read / Update / Delete 四行。Detailed Metrics可折叠每个键类型、每个操作额外给出 Total Time、Samples、Min / Max / Mean / Std Dev以及 P90、P99.9仅在结果非零时显示若 crud-bench 输出中带有 CPU / Memory 数据也会列出。Methodology说明基准参数与所用工具。两个读表要点直接来自 分析脚本吞吐格式规则≥ 1,000,000 显示为X.XM ops/s≥ 1,000 显示为X.Xk ops/s否则显示为X ops/s。看到12.3k ops/s就是每秒约 12,300 次操作。延迟单位是自动换算的crud-bench 的原始 JSON 里延迟以微秒µs存储分析脚本统一乘 1000 转成纳秒后再格式化显示≥ 1,000,000,000 ns 显示为秒≥ 1,000,000 ns 显示为 ms≥ 1,000 ns 显示为 μs其余显示为 ns。所以汇总表里的 P50 显示为1.2ms时对应原始 JSON 里是约 1200 的q50值——直接下载 artifact 里的result*.json手工核对时注意q50/q95/q99的单位是 µs不要和表里的显示单位混用。除了 PR 注释结果还以 Actions artifacts 形式保存可以从对应 workflow run 页面下载doc/BENCHMARKING.mdCurrent results每个配置一个独立 JSON 文件保留 30 天Analysis reportreport.md和analysis.json保留 90 天。注释末尾附有该次 workflow run 的链接可顺着它找到日志和 artifacts。拿到注释后按什么顺序判断文档给出的 review 顺序Interpreting Results 的 What to Look For 一节是四步Verify expected performance核对性能是否符合你对本次改动的预期。改动没碰存储路径时吞吐和延迟应与基线接近改动确实优化了某条路径时对应配置应有可见提升。Compare configurations横向比较不同存储引擎。同一键类型下memory 与 rocksdb、内嵌与网络的差异能帮你判断回退是否集中在某一存储后端。Identify anomalies找异常低的吞吐或异常高的延迟尤其是相对同一次运行内其他配置/键类型的离群值。Review across operations确认改动是否只影响特定 CRUD 操作。例如只改写了更新逻辑理应只有 Update 行变化而 Create/Read/Delete 保持平稳。各指标的定义按文档口径Throughput越高越好衡量每秒能完成多少次操作P50中位数一半的操作比这个时间快P9595% 的操作比这个时间快P9999% 的操作比这个时间快。吞吐反映整体承载能力P95/P99 反映尾部延迟的稳定性。文档没有给出任何固定的通过阈值——注释就是给人看的判断责任在 reviewer。数字对不上时噪声来源与复核手段基准结果会因以下原因波动文档 Variability 一节明确列出CI runner variance不同 runner 的硬件性能特征不同System load后台进程影响计时Network overhead网络类配置对网络条件敏感Warmup effects首次运行可能比后续运行慢。文档给出的复核建议是三条多次运行基准、与本地开发环境的结果对照、看多个 commit 之间的趋势而不是单次运行。结合工具版本固定的设计最稳的做法是同一CRUD_BENCH_REVISION下跨多次运行看趋势单次离群值先重复触发一次再下结论。手动重新触发的路径文档 Manually Running Benchmarks 与 Manual Override 两节打开仓库Actions页选择Performance Benchmarks工作流点击Run workflow选择分支可选在crud_bench_revision输入框填入 commit hash、tag 或分支名可测试其他 crud-bench 版本而无需修改工作流再次点击Run workflow。一个现状说明当前 crud-bench.yml 中pull_request触发器被注释掉注释写明是临时禁用以便手动跑基准而文档描述的PR 打开/同步/重开时自动运行依赖该触发器启用。因此若某 PR 没有自动出现基准注释先检查工作流触发配置与手动运行入口而不是假设基准已跑。注释异常或基准失败时的排查入口注释显示 ⚠️ Benchmark analysis failed. Check the workflow logs for details.说明 Python 分析脚本失败。按文档 Analysis Script Errors 一节确认 JSON 格式符合 crud-bench 预期输出、确认结果文件确实由 crud-bench 生成、查看 workflow 日志中的解析错误。报告显示 No benchmark results found. Benchmarks may have failed.没有可用的 JSON 结果先查各 benchmark job 是否产出benchmark-results-*artifact。job 级失败按文档 Benchmark Failed to Run 一节检查 workflow 日志——构建失败server 二进制编译失败、服务器启动/就绪失败、超时每个 benchmark job 的 timeout 为 30 分钟见 crud-bench.yml。运行偏慢文档给出的预期是 24 个 job 并行、runner 充足时总墙钟时间约 5–7 分钟若单个 job 太慢可参考 Benchmarks are Slow 一节调整这些是对工作流文件的修改操作属于维护基准本身不是解读结果的一部分降低样本量文档建议把样本参数改为-s 5000或-s 2500注意上文提到的冲突文档引用的是-s 10000当前文件实际是-s 100000降低并发把-c 12 -t 48调低文档示例为-c 8 -t 16跳过特定组合在矩阵exclude:中加入配置/键类型组合文档给出的示例exclude: - config: rocksdb key_type: string250边界与限制所有数字来自 CI runner 环境不代表你本地或生产环境的绝对性能只用于同版本工具下的相对对比。24 个 job 各自独立、数据库干净起步结果之间互不干扰但也意味着没有跨 job 的累计状态效应。工具版本升级是有意的受控操作文档 How to Upgrade crud-bench找到目标 revision → 更新CRUD_BENCH_REVISION→ 用 workflow dispatch 测试 → 提交验证升级之后新旧版本的结果不再可比。【免费下载链接】surrealdbA scalable, distributed, collaborative, document-graph database, for the realtime web项目地址: https://gitcode.com/GitHub_Trending/su/surrealdb创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考