实验名称不能代替实际配置
区块链基准测试要能被他人理解，首先应说明测试运行的条件。Caliper把基准配置与调整工具内部行为的运行配置分开：前者主要描述工作负载的执行及结果采集。文档也提醒，配置理论上可独立于被测系统，但实际工作负载的实现可能只适用于某类系统。因此，一份配置文件不能直接证明所有环境都能运行同一个实验。
资料归档可以把工具及连接器版本、被测系统版本、节点部署、机器资源和配置文件放到同一实验编号下。这是本文建议的复现记录，不是声称Caliper会自动收集全部信息。文件名相同也不保证内容相同；若模块后来改过，应保留当次文件或可定位其内容的版本标识，避免拿新代码解释旧结果。
每一轮提交多少和提交什么分别说明
Caliper的rounds数组按轮次描述实验，txNumber表示该轮应提交的交易数量，txDuration表示持续提交交易的秒数；rateControl决定调度节奏，workload负责构造实际交易内容。worker进程数量也有独立设置。这些字段回答不同问题，不能把目标提交速率直接填作系统已经完成的吞吐量。
设两份完全虚构的实验卡，都计划提交一千次操作。甲使用查询模块，乙使用修改状态的模块；仅凭操作次数相同，不能把结果当成同一负载的速度对比。即使模块名称一致，传入参数改变，也可能改变业务行为。记录应保留轮次标签、终止条件、速率控制器类型及参数、模块路径和业务参数，而不是只留一张最终报表。
负载发生端也会影响计划是否实现
Caliper工作负载文档说明，worker会在速率控制器允许下一次交易时调用submitTransaction。这个函数位于生成负载的关键路径，计算开销过重可能影响调度精度；文档建议把适合提前完成的处理放进初始化阶段。由此，结果异常时也要查看生成端的实现，不能预设所有不足都来自区块链节点。
独立的Grafana k6文档用dropped_iterations统计未发出的迭代，并区分执行器配置和被测系统响应变慢等原因。例如，到达率执行器没有空闲虚拟用户时，可能无法启动计划中的迭代。这只是另一种负载工具的具体机制，不表示Caliper具有同名计数，也不能把一次k6迭代等同一笔链上交易；它提示研究记录应交代目标负载是否真正发出。
结果文件要能追溯到原始轮次
Caliper的初始化接口会接收worker编号、总worker数、轮次编号和该轮参数；轮次结束还有清理接口。整理实验时，可以利用这些上下文把日志与轮次对应，并说明初始化数据如何准备、结束后如何清理。若前一轮留下了状态，后一轮又使用该状态，就应把这种依赖写清楚，不能仅凭轮次名称不同就认定彼此独立。
监控设置还决定管理进程从哪里采集哪些指标。可复查的材料应同时保留配置、工作负载实现、依赖版本、原始输出和已知中断，再解释报告中的数字属于哪个范围。本文只阅读工具文档并构造记录示例，没有发起压力测试、测出性能上限或验证某套生产环境；配置完整是复现的准备，实际能否复现仍须按相同条件执行后判断。