Optimism的基准测试可重复性

TL;DR:

• 基准测试结果必须可复现才能被信任

• OP Labs 近期做出了一些改进以实现可复现的结果

• 在可复现性改进后，负载测试的不稳定性从 42% 降至 <1%

衡量一条链的持续吞吐量很容易，但获得一个可信的数字则困难得多。我们必须能够衡量链的性能，以了解当前的能力以及软件/架构变更对性能的影响。为了可靠地将不同运行之间的性能差异归因于软件本身的变更，我们必须首先消除其他潜在的变异性来源：测试工具和方法。如果测量结果不可靠，我们就有可能浪费时间重新运行测试、追逐虚假线索，而不是解决真正的性能瓶颈。

在 OP Labs，我们有一个专门构建基准测试工具的团队，目标是产出可复现的结果，使结果可靠、可操作，并能自信地分享给用户/客户。我们使用一个名为 contender 的开源交易垃圾发送器，这意味着外部方不必仅相信我们的结果。他们可以通过 contender 触发负载测试，针对任何兼容 EVM 的 RPC 端点来验证结果。

变异的潜在原因

• 硬件类型：测试期间承载执行层、共识层等的云或本地机器类型

• 链配置：gasLimit、gasTarget、出块时间、是否启用 Flashblocks

• 执行层配置：内存池大小

• 负载测试类型：负载测试期间挖掘的交易类型；某些交易类型比其他类型更容易处理，因此我们应明确与任何 Mgas/s 或已挖出 TPS 值相关的流量模式

• 负载测试持续时间：短时间的高吞吐量爆发不如长期持续的吞吐量可靠

• 网络延迟：交易垃圾发送器与目标网络/链之间的地理位置关系

如何消除测试变异性

链配置一致性

首先，为我们测试的任何链选择一个合理且一致的默认配置。通常，我们通过向最外层的 proxyd URL 发送垃圾交易来对整条链进行黑盒负载测试，并通过负载测试期间链产生的区块来测量结果。这样我们可以紧密模拟链的生产环境，并识别任何层面的瓶颈——无论是 proxyd 入口加其他网络跳数、数据可用性吞吐量，还是 L2 区块构建器本身。但如果链中每个附加组件的配置不保持一致，就会引入新的潜在变异性。如果在连续运行之间改变太多变量，就很难准确找出影响性能的具体因素。

可靠的测试工具

我们使用的主要基准测试工具包括：

• contender：开源交易垃圾发送器；由 Flashbots 构建，OP Labs 工程师做出了重要贡献

• op-benchmark：围绕 contender 的闭源封装，能够感知并访问 OP Labs 开发网络内部；提供更详细的指标/数据，并允许我们在每次运行之间清空内存池，确保每次负载测试都从相同的干净状态开始（即不受之抢跑的影响）

Contender 支持多种交易类型（在 contender 代码库中称为“场景”），我们可以在给定负载测试中使用。有一些内置场景，也支持基于 TOML 的自定义场景。如果我们在不同负载测试之间使用的交易类型不一致，那么这可能是最终用于表示整体吞吐量的 Mgas/s 和已挖出 TPS 值的主要变异来源。如果“gas”能够完美代表排序器处理该交易所付出的努力，那么交易类型就无关紧要。目前，OP Labs 主要关注以下 contender 场景，以比较不同链/开发网络的性能：

• erc20

  • 从有限的“发送地址”池向随机的代币接收者进行代币转账

  • 约 55k gas/交易

  • 给存储带来压力，因为每笔交易都会触及唯一的存储槽

• groth16Verify

  • Groth16 零知识证明验证

  • 约 300k gas/交易

  • 给 CPU 带来压力，因为椭圆曲线运算对 CPU 要求高

• （未来）uniV3

  • Uniswap 中一种代币交换为另一种代币

  • 许多链上常见的交易类型，适用于许多 OP Enterprise 客户的目标

性能最差的场景帮助我们设定给定链在面临 DOS 攻击（无法以发送速度处理有效用户交易）之前所能使用的最大 gasTarget 和 gasLimit 阈值。

我们还为那些预期特定应用/交易会消耗其链上大量区块空间的客户构建自定义场景。我们未来的计划包括扩展标准场景套件，将其作为每个基准测试流程的一部分，以从不同维度对潜在瓶颈进行压力测试。

近期改进

有一段时间，我们在近一半的高负载测试（持续运行 >1 分钟）中意外出现了灾难性失败。这使得很难区分负载测试是找到了最大吞吐量，还是临时性问题破坏了测试结果。在对基准测试工具和核心 op-stack 组件实施修复后，负载测试现在更加鲁棒/可靠。临时事件（例如单个 RPC 故障、L1 衍生）现在只会导致吞吐量出现小幅暂时下降，而不会引发连锁故障导致整个负载测试被丢弃（例如引入 nonce 间隙，导致所有未来的交易无法被打包进区块）。

三项改动起到了最大作用：

• contender：增强对临时 RPC 故障的鲁棒性（已合并的 PR）；防止单个 RPC 故障因 nonce 间隙而导致整个负载测试失败

• op-node 配置：使用 light-CL 模式，将 L1 衍生外包给独立的 RPC 节点，而不是在排序器内部完成该工作。这消除了 op-node 内部的一些争用，因为区块构建和 L1 衍生运行在同一个线程中。这类问题通常被描述为“衍生管道停滞”或“FCU 雪崩”

• op-reth 配置：增加内存池中最大待处理/排队交易数，以增强对暂时性吞吐量波动的鲁棒性，避免内存池达到容量上限而开始丢弃交易，从而导致 contender 发送的交易出现 nonce 间隙

结果

在改进基准测试可复现性之前，我们的结果波动很大。当我们运行相同的负载测试（即对同一目标链使用相同的测试配置）时，测试大多数时候通过，但重新运行时也经常失败。这里的“通过”意味着所有发送的交易都成功被挖出，并且链总体健康。对于某个特定的高负载测试（场景：erc20，TPS：1700），我们出现了 58/42 的通过/失败比例。

在修复和重新配置之后，相同的重新运行 100% 成功（n=66）。这是一个巨大的改进，使我们能够信任结果，避免浪费时间调试不稳定的测试。这意味着我们可以投入更多时间来识别和解决实际的性能瓶颈，从而为客户和用户带来真正的价值。

• 原文链接： optimism.io/blog/benchma...
• 登链社区 AI 助手，为大家转译优秀英文文章，如有翻译不通的地方，还请包涵～