Paradigm：了解区块链的延迟和吞吐量

文章来源：FastDaily 

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

关键指标和它们的互动

在开发区块链系统时应考虑两个重要指标：延迟和吞吐量。用户关心的第一件事是交易延迟，或者说从发起交易或支付到收到确认交易有效的时间。在经典的BFT系统（如PBFT、Tendermint、Tusk & Narwhal等）中，交易一旦得到确认就会最终完成，而在最长链共识（如Nakamoto Consensus、Solana/Ethereum PoS）中，交易可能被纳入一个区块，然后被重新聚合。因此，我们需要等到一个交易 "深入到k个区块"，从而导致延迟明显大于单一确认。

第二，系统的吞吐量对系统设计者来说通常很重要。这是系统在单位时间内处理的总负荷，通常以每秒交易量表示。乍一看，这两个关键指标似乎是彼此的反义词。因为吞吐量是以每秒的交易量来衡量的，而延迟是以秒来衡量的，所以我们自然会认为吞吐量=负载/延迟。然而，情况并非如此。这种认识是困难的，因为许多系统倾向于制作图表，在Y轴上显示吞吐量或延迟，在X轴上显示诸如节点数量的东西。相反，一个更好的图形生成是吞吐量/延迟图，它通过不是线性的方式使之明显。

当链上竞争很少时，延迟是恒定的，而吞吐量可以通过改变负载来改变。出现这种情况的原因是，提交一个事务的最低成本是固定的，而且在低竞争的情况下，队列延迟为零。在高度竞争下，吞吐量是恒定的，但延迟可以通过改变负载而变化。这是因为系统已经过载，增加更多的负载会导致等待队列无限地增长。更为反常的是，延迟似乎随着实验长度而变化。

所有这些在经典的L图 上都是可见的，这取决于到达时间的分布（如后面所讨论）。因此，从这篇博文中得到的关键启示是，我们应该在热区进行测量，在那里吞吐量和延迟都会影响我们的基准，

测量方法

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

开环与闭环

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

测试正确的场景是至关重要的，因为与闭环系统相比，闭环系统的延迟通常受制于潜在未决请求的数量，而开环系统可能会产生大量的排队，因此，延迟会更长。一般来说，区块链协议可以被任何数量的客户使用，并在开环环境中得到更准确的评估。

综合基准的到达间隔分布

在创建合成工作负载时，要问的一个问题是如何提交请求。许多系统在测量开始前就预装了事务，但这使测量结果有偏差，因为系统从不寻常的0状态开始。此外，预装的请求已经在主内存中，因此绕过了网络堆栈。一个稍微好一点的方法是以一个确定的速率发送请求（例如，1000 TPS）。这将导致一个L型图（橙色），因为系统的容量得到了最佳利用。

然而，开放系统经常不会以一种可预测的方式行事。相反，它们有高负荷和低负荷的时期。为了对此进行建模，我们可以采用概率性的到达率分布，这将导致 "曲棍 "图（蓝线），因为泊松突发将导致一些排队延迟（最大容量），即使平均速率低于最佳。这对我们是有利的，因为我们可以看到系统是如何处理高负载的，以及当负载恢复到正常时，它的恢复速度如何。

热身阶段

最后要考虑的一点是何时开始测量。我们希望在开始之前，链上已经充满了交易；否则，热身延迟将被测量。这最好是通过在热身阶段测量延迟来完成，直到测量结果遵循预期的分布。

如何比较

最后的困难是在基础上比较系统的各种部署。同样，困难在于延迟和吞吐量是相互依赖的，所以可能很难产生一个公平的吞吐量/节点数图表。与其简单地将每个系统推到其最大吞吐量（在这里延迟是没有意义的），最好的方法是定义一个服务水平目标（SLO），并测量这一点的吞吐量。在吞吐量/延时图上画一条水平线，与延时轴在SLO处相交，并对那里的点进行采样，这是一种很好的可视化方法。

但是我设置了一个5秒的SLO，它只需要2秒。

有人可能会想增加这里的负载，以便利用饱和点之后的少量高吞吐量，但这是很危险的。如果系统操作的配置不足，突如其来的请求将导致系统达到完全饱和，导致延迟的爆炸和非常迅速地违反SLO。从本质上讲，在饱和点之后运行是一种不稳定的平衡。因此，有两点需要考虑。

过度配置你的系统。从本质上讲，系统应该在饱和点以下运行，这样才能吸收到达率分布中的突发事件，而不是导致排队延迟的增加。

如果你的SLO下有空间，增加批处理量。这将增加系统关键路径上的负载，而不是排队延迟，并获得你正在寻找的高吞吐量与高延迟之间的权衡。

我正在产生一个巨大的负载，我怎样才能测量延迟？

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

一个更系统的方法是有两个负载生成器。第一个是主负载发生器，它遵循泊松分布。第二个请求生成器测量延迟，其负载要低得多；与系统的其他部分相比，可以把它看作一个单一的客户。即使系统对每一个请求都进行回复（就像一些系统那样，比如KV-存储），我们也可以放弃对负载发生器的所有回复，并且只测量来自请求生成器的延迟。唯一棘手的部分是，实际的到达间隔分布是两个随机变量的总和）。

结论

测量一个大规模的分布式系统对于识别瓶颈和剖析压力下的预期行为至关重要。我们希望通过使用上述方法，我们都能向共同语言迈出第一步，这将最终导致区块链系统更适合它们所做的工作和对终端用户的承诺。在未来的工作中，我们计划将这一方法应用于现有的共识系统。