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

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

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

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

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

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

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

结论

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