Aptos Move e2e-benchmark 校准日志calibration_values.changelog解析wall-time 漂移检测与基准校准全流程【免费下载链接】aptos-coreAptos is a layer 1 blockchain built to support the widespread use of blockchain through better technology and user experience.项目地址: https://gitcode.com/GitHub_Trending/ap/aptos-core本文围绕 Aptos 核心仓库中的 calibration_values.changelog.md 展开深入解析 Move 虚拟机端到端基准e2e-benchmark校准日志的结构、字段含义以及它背后的漂移检测—校准值更新—日志记录自动化体系。读完本文你将掌握如何读懂一条校准记录transaction_type / runs / wall-time % change、校准值文件 calibration_values.tsv 与日志的对应关系、基准程序 main.rs 的回归/改进判定算法以及如何通过 single_node_performance_calibration.py 手工触发一次校准并维护日志。一、这份校准日志是什么aptos-move/e2e-benchmark/data/calibration_values.changelog.md是 Move e2e-benchmark 的校准历史记录recalibration history按最新在前newest first的顺序追加。日志头部明确给出了它的用途Recalibration history, newest first. Each entry lists the tests whose calibrated value drifted out of band, as a signedwall-time % change(positive means slower); new tests shownew.即每次校准recalibration发生时将漂移出允许带宽out of band的基准测试以表格形式记录下来变化量用带符号的wall-time % change表示正数代表变慢而新增测试此前没有校准基线则标记为new。截至当前仓库状态日志仅包含一次校准事件## 2026-08-27transaction_typerunswall-time % changeVectorPicture { length: 30720 }1425.0%VectorPictureRead { length: 30720 }1426.2%该条目说明在 2026-08-27 的校准中VectorPicturelength 30720与VectorPictureReadlength 30720两个基准的实测耗时中位数相对旧的期望值分别变慢了 25.0% 和 26.2%超出允许带宽触发了校准值重写。二、日志格式与字段语义从日志本身的头部注释以及生成它的 single_node_performance_calibration.py 源码format_changelog_entry、changelog_header、update_changelog三个函数可以确认该日志的完整格式约定1. 固定头部块# Move e2e-benchmark calibration log Recalibration history, newest first. Each entry lists the tests whose calibrated value drifted out of band, as a signed wall-time % change (positive means slower); new tests show new.头部块只在文件首次创建时写入changelog_header函数之后的条目插入到头部之下、最旧条目之上保证最新在前。2. 条目结构每个条目以## YYYY-MM-DD日期标题开头随后是一个 Markdown 表格列名含义transaction_type基准测试的事务类型即 main.rs 中EntryPoints枚举的 Debug 字符串如VectorPicture { length: 30720 }runs新校准值采样覆盖的样本数即 Humio 查询窗口内参与计算中位数的运行次数次数低意味着噪声大、可能是单次运行wall-time % change带符号百分比(new - old) / old * 100保留 1 位小数正数表示变慢回归负数表示变快改进无旧基线的新测试显示为new对比参照单节点性能校准日志 single_node_performance_values.changelog.md 使用完全相同的机制但其度量为tps % change负数为变慢且表格额外包含module_working_set、executor两列——这是由两者度量方向相反wall-time 越低越好、tps 越高越好决定的。3. 条目何时写入update_changelog函数的注释明确了一条纪律只有本次运行实际重写了.tsv校准值文件时changelog 才会被更新。若一次校准运行没有任何生产行漂移出带宽则不会创建/触碰 changelog——否则校准工作流会错误地开出只含空 changelog 的 PR。此外日志文件是按需创建的而非仓库中始终跟踪这样首次校准提交是一个新增文件new-file addcreate-pull-request可以干净地 cherry-pick 到目标分支。三、校准值的真实载体calibration_values.tsv日志中每一条记录的最终落点是 calibration_values.tsv。该文件每行一个测试用制表符分隔五列由 main.rs 的get_parsed_calibration_values()在编译期通过include_str!直接嵌入二进制transaction_typeEntryPoints的{:?}Debug 输出作为 HashMap 的 keyruns/ count采样次数当前源码中该字段被注释为未使用count: usize被注释掉min_ratiomin / 中位数第 50 百分位之比max_ratiomax / 中位数之比expected_time_micros期望耗时微秒以日志中漂移的两行为例TSV 中的对应记录为VectorPicture { length: 30720 } 14 0.747 1.030 4965.8 VectorPictureRead { length: 30720 } 14 0.749 1.028 4956.7注意日志中的25.0%/26.2%是本次校准前后期望值的变化幅度(new - old) / old而 TSV 中现在的expected_time_micros4965.8µs、4956.7µs已经是更新后的新基线。整份 TSV 覆盖了循环、对象创建、VectorPicture、SmartTablePicture、Resource Groups、Token V1/V2、流动性池、Fungible Asset、事件发射、向量修剪/插入/区间移动、Map 增删等 30 个基准全部为 14 次采样。四、基准程序如何产出这些数据校准数据的测量端在 aptos-move/e2e-benchmark/src/main.rs。其主流程为set_layout_caches(true)初始化 VM 布局缓存FakeExecutor::from_head_genesis()从头创世构建一个确定性执行环境并set_not_parallel()关闭并行以测得单线程上限。通过get_parsed_calibration_values()加载内嵌的 TSV 校准值。遍历entry_points列表对每个入口点随机发布所需的 Move 包PackageHandler若有初始化入口如InitializeVectorPicture先执行初始化事务调用execute_and_time_entry_point()通过exec_func_record_running_time计时——迭代次数由期望耗时决定expected_time_micros 1000时跑 100 次否则跑 500 次计算diff (elapsed - expected) / expected * 100并统计执行 gas、IO gas 与 gas/s输出两行结果一行人类可读的表格一行 JSONgrep_json_aptos_move_vm_perf供 Humio 采集。entry_points列表中每个元组的第一项是flow标记LANDBLOCKING_AND_CONTINUOUS或ONLY_CONTINUOUS用于区分阻塞性回归测试每次都必须跑与仅持续监控测试可通过--only-landblocking跳过。回归/改进判定算法main.rs中定义了三个关键常量const ALLOWED_REGRESSION: f64 0.15; // 允许 15% 回归 const ALLOWED_IMPROVEMENT: f64 0.15; // 允许 15% 改进 const ABSOLUTE_BUFFER_US: f64 2.0; // 2 微秒绝对缓冲对每个测试分别计算上下界let max_regression f64::max( expected_time_micros * (1.0 ALLOWED_REGRESSION) ABSOLUTE_BUFFER_US, expected_time_micros * cur_calibration.max_ratio, ); let max_improvement f64::min( expected_time_micros * (1.0 - ALLOWED_IMPROVEMENT) - ABSOLUTE_BUFFER_US, expected_time_micros * cur_calibration.min_ratio, );若elapsed max_regression记录Performance regression detected失败信息若elapsed max_improvement记录Performance improvement detected失败信息并提示需要更新期望值任一失败都会使程序exit(1)并额外断言运行期间无 error 日志aptos_logger::ERROR_LOG_COUNT必须为 0。绝对值缓冲2µs的存在是为了避免对耗时极短几微秒的测试做无意义的百分比判定而min_ratio/max_ratio则来自历史采样分布二者取 max/min 得到更宽松且更符合噪声分布的门槛。五、校准值如何被刷新从 Humio 查询到 changelog校准值的更新由 testsuite/single_node_performance_calibration.py 完成文档注释见 single_node_performance.py本地运行./testsuite/single_node_performance_calibration.py --branchYOUR_BRANCH更新单节点校准值加--move-e2e更新 Move e2e 校准值。其核心步骤如下查询指标以grep_json_aptos_move_vm_perfmove-e2e 路径或grep_json_single_node_perf单节点路径过滤 CI 日志按test_index, transaction_type分组聚合出count、expected、avg/min/max、第 50 百分位中位数并计算min_ratio min / p50、max_ratio max / p50。对比现有 TSV_load_existing_tsv逐行判断每项测试是否漂移出带宽——漂移行记为(drift, old, new)无历史基线的记为(new, ...)同时区分低采样行、实验性跳过行与无法解析行。重写 TSV仅当存在触发行时重写aptos-move/e2e-benchmark/data/calibration_values.tsv采样数过少噪声过大的行保持旧值避免被其他行的漂移顺带改写。更新 changelog重写 TSV 的同时调用update_changelog将本次触发行渲染为 Markdown 表格并插入到头部之下delta (new - old) / old * 100保留一位小数新测试显示new。日期取自datetime.date.today().isoformat()。这解释了日志头部那句newest first的实现方式不是简单追加到文件末尾而是通过正则^##定位现有最旧条目把新条目插在它之前、固定在头部块之后。六、如何运行 e2e-benchmark 验证校准基准程序属于aptos-move工作区的独立 crateCargo.toml包名aptos-move-e2e-benchmark。参考 testsuite/single_node_performance.py 中的调用方式构建与运行命令为# 1. 构建单节点性能脚本中的 BUILD_FLAG 通常为 --release cargo build --release --package aptos-move-e2e-benchmark # 2. 运行全量校准含 landblocking 与 continuous RUST_BACKTRACE1 ./target/release/aptos-move-e2e-benchmark # 3. 仅运行 landblocking 阻塞性测试 ./target/release/aptos-move-e2e-benchmark --only-landblocking运行时会输出两类内容人类可读表格walltime(us)、expected(us)、dif(- is impr)相对期望的百分比偏差、gas/s、exe gas、io gas逐行列出每个入口点JSON 行以grep_json_aptos_move_vm_perf为 grep 标签包含transaction_type、wall_time_us、expected_wall_time_us、expected_max_wall_time_us、expected_min_wall_time_us、gas_units_per_second、execution_gas_units、io_gas_units、code_perf_version当前v1、test_index、flowLAND_BLOCKING/CONTINUOUS。这些 JSON 正是 Humio 校准查询的数据来源。CODE_PERF_VERSION常量当前为v1的注释说明了它的用途在较大的性能或测试改动后 bump 版本号便于区分运行在同一 commit 之上还是之外的测量结果。此外源码中还保留了一批被注释掉的入口点如Nop、BytesMakeOrChange、低代价 BCS 序列化等注释说明它们对计时器来说太快或不能代表真实 BCS native 调用成本——这提示校准基准有意避开了耗时过短、噪声过大的场景。七、如何解读一条校准记录以 2026-08-27 为例结合以上机制回看日志中的唯一条目## 2026-08-27 | VectorPicture { length: 30720 } | 14 | 25.0% | | VectorPictureRead { length: 30720 } | 14 | 26.2% |可以推断出完整的事件链CI 周期性地在 main.rs 的固定入口点列表上运行基准VectorPicture { length: 30720 }属于ONLY_CONTINUOUS流程即持续监控而非 landblocking 门禁。一段时间内这两个大向量30 × 1024 个元素基准的耗时中位数相对旧期望值分别上升 25.0% 与 26.2%超出ALLOWED_REGRESSION 0.15与ABSOLUTE_BUFFER_US 2.0构成的带宽。校准脚本检测到 out-of-band 漂移后将 TSV 中这两行的expected_time_micros重写为新中位数4965.8µs / 4956.7µs并据此在 changelog 中插入本次条目runs 14表示新值来自 14 次采样窗口内的中位数。校准 PR 被合并后main.rs 在后续 CI 中改用新基线判定回归——此时任何使耗时超过max_regression max(4965.8×1.152, 4965.8×1.030) ≈ 5712.7µs的改动才会被标记为性能回归。八、注意事项与适用范围度量方向move-e2e 校准以 wall-time微秒为度量正数为变慢而单节点校准以 tps 为度量负数为变慢。解读日志时必须注意这一差异。采样噪声runs越小中位数越可能是单次或少量运行的结果噪声越大校准脚本对低采样行采取保持旧值策略避免噪声污染基线。环境前提校准值是在固定规格机器与固定执行环境FakeExecutor::from_head_genesis、非并行、固定种子 RNG、max_gas_amount 2_000_000、gas_unit_price 200下测得的换机器或改基准参数后得到的绝对耗时不可直接与仓库内基线对比。判定门限的工程取舍15% 的允许回归/改进带宽加 2µs 绝对缓冲是仓库在减少 CI 噪声误报与及时捕捉真实性能变化之间的折中min_ratio/max_ratio参与上下界计算使门限贴合每个测试自身的耗时分布。九、总结calibration_values.changelog.md虽然只有寥寥数行却是 Aptos Move VM 性能回归防护体系中人类可读审计记录的一环它的上游是 calibration_values.tsv机器可读基线与 main.rs测量与判定下游是 single_node_performance_calibration.py自动化校准与日志维护。理解这条链路即可在日常开发中正确解读校准日志、判断某次基准结果是否触发漂移并知道在性能改动后如何重新校准基线。【免费下载链接】aptos-coreAptos is a layer 1 blockchain built to support the widespread use of blockchain through better technology and user experience.项目地址: https://gitcode.com/GitHub_Trending/ap/aptos-core创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考