大纲

• 1. 关键指标及其相互作用
• 2. 测量方法论
  • 1. 开环与闭环
  • 2. 合成基准的到达间隔分布
  • 3. 热身阶段
• 3. 如何比较
  • 1. 但我设置了5秒的SLO，而它只需2秒。
  • 2. 我正在产生巨大的负载。我该如何测量延迟？
  • 3. 结论

如何正确测量一个（区块链）系统是其设计和评估中最少被讨论但最重要的步骤之一。目前有许多共识协议和变化，具有不同的性能和可扩展性权衡。但迄今为止，仍然没有一个普遍认可的、可靠的方法可以实现全面的比较。在这篇博客文章中，我们概述了一种受数据中心系统测量启发的方法，并讨论在评估区块链网络时应该避免的常见错误。

关键指标及其相互作用

在开发区块链系统时，需要考虑两个重要指标：延迟和吞吐量。

用户首先关注的是事务的 加粗延迟，即从发起交易或付款到收到其有效的确认（例如，确认用户有足够资金）之间的时间。在经典的 BFT 系统（例如 PBFT、Tendermint、Tusk & Narwhal 等）中，一旦交易被确认，它就被视为完成，而在最长链共识（例如 Nakamoto Consensus、Solana/Ethereum PoS）中，交易可能被包含在区块中，然后被重组。因此，我们需要等到交易“深度达到 k 个区块”，这导致的延迟明显大于单次确认的延迟。

其次，系统的 加粗吞吐量通常对系统设计者非常重要。这是系统在单位时间内处理的总负载，通常以每秒的交易数表示。

乍一看，这两个关键指标似乎是相互矛盾的。因为吞吐量以每秒交易数来衡量，而延迟则以秒来衡量，我们自然会期望吞吐量 = 负载 / 延迟。

然而，事实并非如此。这种认识是困难的，因为许多系统往往生成显示吞吐量或延迟在纵轴上、节点数在横轴上的图形。相反，生成吞吐量/延迟图是一种更好的选择，因为其不是线性的，显示出真实情形。

当争用很小的时候，延迟是恒定的，而吞吐量可以通过改变负载来变化。这是因为提交一个交易有一个固定的最低成本，并且在低争用时队列延迟为零，导致“无论什么进来，直接出去”。

在高争用时，吞吐量是恒定的，但延迟可以通过改变负载来变化。

这是因为系统已经过载，增加更多负载会导致等待队列无限增长。更值得注意的是，延迟似乎会随着实验时长而变化。这是由于无限增长的队列造成的伪影。

所有这些情况在经典的“曲棍球棒图”或者“L图”中都可以看到，这取决于到达间隔分布（稍后将讨论）。因此，这篇博客文章的关键要点是，我们应该在热区中进行测量，在这个区域，吞吐量和延迟都会影响我们的基准，而不是在边缘区域，在这里只考虑其中一个指标。

测量方法论

在进行实验时，有三种主要的设计选项：

开环与闭环

控制请求流向目标的主要方法有两种。开环系统由 n = ∞ 个客户端根据速率 λ 和到达间隔分布（例如，泊松分布）发送请求进行建模。闭环系统限制任何给定时间内的未完成请求数。开环和闭环系统之间的区别是特定部署的特征，同一系统可以在不同的场景中进行部署。例如，一个键值存储可能在开环部署中为数千个应用服务器服务，或在闭环部署中只为少数阻塞客户端服务。

测试正确的场景至关重要，因为与闭环系统相比，后者的延迟通常受潜在未完成请求数量的限制，而开环系统可能产生显著的排队，因此结果是更长的延迟。一般来说，区块链协议可以由任意数量的客户端使用，并在开环环境中更准确地评估。

合成基准的到达间隔分布

创建合成工作负载时，自然想知道如何提交请求。许多系统在测量开始之前预加载交易，但这会偏颇测量，因为系统从0的异常状态开始。此外，预加载的请求已经在主内存中，因此绕过了网络栈。

稍微好的方法是以确定的速率发送请求（例如，1000 TPS）。这将导致L形图（橙色），因为系统的容量被最佳利用。

然而，开放系统通常不会以如此可预测的方式运行。它们会有高负载和低负载周期。为了对其建模，我们可以采用基于泊松分布的概率到达间隔分布。这将导致“曲棍球棒”图（蓝色线），因为泊松波动会在即使平均速率低于最佳时仍然导致一定的排队延迟（最大容量）。这对我们是有益的，因为我们可以看到系统如何处理高负载，以及在负载恢复正常时恢复的速度。

热身阶段

最后一个要考虑的点是何时开始测量。我们希望在开始之前管道中充满交易；否则将会测量热身延迟。这应 ideally 在热身阶段测量延迟，直到测量遵循预期的分布。

如何比较

最后一个难点是以公正的方式比较系统的不同部署。再次，由于延迟和吞吐量是相互依赖的，因此可能很难生成一个公平的吞吐量/节点数图表。与其简单地将每个系统推向其最大吞吐量（而延迟对此毫无意义），最好的方法是定义服务水平目标（SLO）并在此点上测量吞吐量。在吞吐量/延迟图上，绘制一条与延迟轴在 SLO 处相交的水平线，并在该处采样点，是一种很好的可视化方式。

但我设置了5秒的SLO，而它只需2秒。

有人可能会试图在这里增加负载，以利用在饱和点之后可获得的边际高吞吐量。但 这很危险。如果系统操作的资源不足，预期外的请求浪潮将导致系统达到完全饱和，导致延迟激增并快速违反SLO。本质上，在饱和点之后的操作是一个不稳定的平衡。因此，有两个要点要考虑：

1. 对系统进行过度配置。 本质上，系统应该在 饱和点之下 运行，以便在到达间隔分布中的突发被吸收，而不是导致增加排队延迟。
2. 如果在你的 SLO 下有余地，增加批量大小。这将使系统的关键路径负载增加，而不是排队延迟，从而实现你期望的高吞吐量与高延迟之间的折衷。

我正在产生巨大的负载。我该如何测量延迟？

当负载较高时，试图访问本地时钟并为每个到达系统的交易添加时间戳可能会导致偏差结果。相反，还有两种更可行的选择。第一种最简单的方法是对交易进行抽样；例如，某些交易中可能有一个神奇数字，只有这些交易的客户端才保留一个计时器。在提交时间后，任何人都可以检查区块链以确定这些交易何时提交，从而计算其延迟。这种做法的主要优点是不会干扰到达间隔分布。然而，由于某些交易必须被修改，这可能会被视为“黑客”手段。

更系统的方法是有两个负载生成器。第一个是主要负载生成器，遵循泊松分布。第二个请求生成器测量延迟且负载较低；可以将其视为相对于系统其余部分的单个客户端。即使系统对每一个请求（某些系统会这么做，例如键值存储）发送回复，我们也可以轻松地丢弃所有对负载生成器的回复，只测量请求生成器的延迟。唯一棘手的部分是，实际的到达间隔分布是两个随机变量的和；然而，两个泊松分布的和仍然是泊松分布，所以数学并不复杂：）。

结论

测量一个大规模分布式系统对于识别瓶颈和预测在压力下的预期行为至关重要。我们希望通过使用上述方法，我们都可以迈出朝着共同语言的第一步，这将最终导致更好地满足其工作需求和向最终用户承诺的区块链系统。

在未来的工作中，我们计划将此方法应用于现有的共识系统，如果你对此感兴趣，请通过 Twitter 联系我们！

致谢：所有这些都是我与我的合著者在设计和实现 [Narwhal & Tusk](https://arxiv.org/abs/2105.11827)（最佳论文奖 @ Eurosys 2022）期间学到的教训，以及 Marios Kogias、Joachim Neu、Georgios Konstantopoulos 和 Dan Robinson 对早期草稿的评论。

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