法拉利与重型半挂卡车

在 SMB 领域工作时，我们其实很少需要谈论延迟。SMB 领域几乎无一例外都聚焦于系统吞吐量，而通常意识不到延迟也是一种需求。但有些时候，延迟会变得很重要，而当它变得重要时，理解吞吐量与延迟之间的相互作用、以及「速度」对我们究竟意味着什么，就至关重要。一旦我们进入企业级领域，延迟更常会被视为一种值得关注的因素，但即便在那里，吞吐量也几乎总是占据着至高无上的地位，以至于关于速度的种种概念几乎无一例外都围绕着吞吐量展开，而关于延迟的种种概念则常常被忽视或遗忘。

理解延迟在一个系统中所扮演的角色可能相当复杂，尽管延迟本身相对而言较易于理解。

在延迟与吞吐量之间，我喜欢用的一个绝佳类比，便是法拉利与重型半挂卡车的设想。法拉利在传统意义上是「快」的，它们拥有很高的「每小时英里数」。有人或许会说，它们是为速度而设计的。但果真如此吗？

我们通常认为重型半挂卡车是慢的。它们是又大又笨重的家伙，最高时速很低。但它们一次能拉运大量的东西。

在计算机的语境里，我们通常把速度想象成拉运能力——我们以「每秒多少件」的方式来思考。就法拉利而言，以每小时两百英里的速度行驶固然很棒，但它一次或许只能拉运一个箱子。一辆重型半挂卡车每小时只能跑一百英里，但一次能拉运接近一千个箱子。当我们谈论计算机上的吞吐量或速度时，我们想到的更多是这种概念。在网络的语境里，我们想到的是每秒多少千兆字节，而很少去关心单个数据包的速度，因为单个数据包很少是重要的。在计算的语境里，我们想到的是诸如每秒多少次浮点运算之类的概念，这是一个类似的概念。没人真正在意单次 FLOP（浮点运算）耗时多久，只在意我们在一秒或十秒内能完成多少次。

因此，当我们审视一辆法拉利时，可以说它拥有每小时两百「箱·英里」的有用速度。也就是说，在每一小时的运行中，一辆法拉利可以把一个箱子移动至多两百英里。一辆重型半挂卡车则拥有每小时十万「箱·英里」的有用速度。就到处运送包裹而言，重型半挂卡车的吞吐量轻轻松松就比法拉利「快」上五百倍。

因此，按照我们通常对计算机和网络的思考方式，重型半挂卡车会是「快」的，而法拉利则会是「慢」的。

但还有延迟需要考虑。假设我们的载荷很小，比方说一封信或一个小箱子，那么一辆法拉利只需五个小时，就能把那一个箱子运送一千多英里！一辆重型半挂卡车走同样的路程则要花十个小时（不过它可以让一大堆信件同时送达）。如果我们所需要的，是把一条消息或一个小包裹非常迅速地从一个地方送到另一个地方，那么法拉利就是更好的选择，因为从我们启动配送到第一个包裹送达，它的延迟（时延）只有重型半挂卡车的一半。

可以想见，在大多数情况下，重型半挂卡车要实用得多，因为它们的配送速度高出太多了。而且，正因如此，我们实际上时时刻刻都能在公路上看到大型卡车，而法拉利的出现率则非常之低——尽管二者的购置成本大致相当（非常粗略地说）。但在某些特殊情形下，法拉利反倒更说得通。只不过这种情形并不多见。

这是一个普适性的概念，可以应用于众多场合。它适用于缓存系统、内存、CPU、网络、操作系统内核与调度器，也适用于汽车等等。延迟与吞吐量通常呈反比关系——我们牺牲延迟，以换取吞吐量。对大多数操作而言，这样做最为合理。但有时为延迟而调优反倒更有意义。

存储在计算领域里其实是个怪胎：几乎所有对存储性能的关注都围绕着 IOPS，而 IOPS 大致是延迟的一个代理度量，而非围绕以「每秒传输的数据量」来衡量的吞吐量。我们很少去关心后面这个数字，因为它几乎从来都不是存储瓶颈的根源所在。但这是例外，而非常规。

延迟与吞吐量在计算世界里可能会有一些出人意料的相互作用。例如，当我们谈论网络时，我们通常只衡量吞吐量（Gb/s），而很少太在意延迟（通常以毫秒为单位来衡量）。这通常是因为，几乎所有网络系统都具有相近的延迟数值，而大多数应用对延迟时延也基本上漠不关心。只有在像跨国链路上的 VoIP 或卫星通信这类罕见应用中，延迟才会影响到普通人；或者当人们尝试某种不寻常的做法——比如在长距离 WAN 连接上跑 iSCSI——时，延迟才会突然冒出来，作为一个未曾预料到的问题让人措手不及。

延迟与吞吐量的相互作用开始变得令人震惊而有趣的场合之一，便是当我们从电气或光学数据网络转向物理网络的时候。业内有一句名言：

永远不要低估一辆满载磁带、在高速公路上飞驰而过的旅行车的带宽。

这绝佳地展示了巨大带宽与极高延迟并存的情形。横穿全城行驶五十英里，一辆旅行车或 SUV 就能拉运数百拍字节的数据，所达到的数据速率是 10GB/s 的光纤所望尘莫及的。但第一个数据包到达所需的时间却约为一个小时。我们常常对这种网络不屑一顾，因为我们假定延迟必定被限定在约 500 毫秒以内。但情况并非总是如此。

澳大利亚最近上了新闻，他们做了一项测试，看看一只携带 SD 卡的鸽子在网络吞吐量方面能否胜过当地的 ISP——结果这只鸽子最终竟比 ISP 还要快！

就计算性能而言，我们常常对延迟视而不见，甚至到了根本意识不到它是一个可用来讨论性能的语境的地步。但在低延迟计算的圈子里，延迟会被极为审慎地加以考量。系统吞吐量通常会被大幅削减（一种常见做法是把系统设定为只达到百分之十的 CPU 利用率，而更为传统的系统则把目标定在接近百分之九十），与此同时还会运用诸如实时内核、CPU 亲和性、处理器绑定、缓存命中率以及降低度量值等种种手段，一切都是为了专注于从系统获得尽可能即时的响应，而非试图从系统中榨取最多的总处理量。

从计算的角度来看，常见的需要低延迟的场合，包括关键的控制器系统（例如制造业的控制器，在那里哪怕一毫秒的延迟都可能在车间里酿成问题），或者金融交易系统（在那里几毫秒的延迟就可能导致投资标的的价格已经发生变动，或者产品已经被售出、不再可供购买）。就延迟而言，速度往往是赚钱还是亏钱之间的决定性因素——哪怕仅仅一毫秒都可能是致命的。

从技术上讲，就连音频和视频处理系统也必须对延迟敏感，但大多数现代计算系统都拥有如此之多的富余处理开销，且延迟通常也足够低，以至于大多数系统——甚至包括 VoIP 的 PBX 和会议系统——如今都能正常运转，仅在极为罕见的情况下才需要在处理一侧顾及延迟方面的问题（就连网络延迟作为一种关注点也正变得越来越不常见）。普通的系统管理员或工程师，很可能轻轻松松就度过整个职业生涯，而从未需要去处理一个对延迟敏感的系统，或一个其可用开销不足以掩盖任何延迟敏感性的系统。

对速度加以界定——无论它指的是吞吐量、延迟，还是别的什么，抑或是二者的某种组合——在 IT 的方方面面以及人生当中都是一件非常重要的事。延迟与吞吐量通常存在一种此消彼长的间接关系，吞吐量的提升以延迟为代价，反之亦然；理解它们在不同情境下如何影响我们、它们彼此之间如何相互作用，并学会按需在二者之间加以权衡，以改善我们所操持的系统，是极有价值的。