延遲與吞吐量

想像一間咖啡店。延遲是「你」從點餐到拿到杯子等了多久。吞吐量是這間店每小時替所有客人端出多少杯。這是不同的問題，而且改善其一可能傷害另一：店家可以把十張訂單湊成一批一起沖以提高效率（吞吐很棒），卻讓你站著等更久（延遲更差）。系統裡幾乎每場效能討論，其實都是在問你要最佳化這兩者中的哪一個。

精確地說：延遲是「一個」操作完成所需的時間，按每個請求量測（毫秒、微秒）。吞吐量是完成操作的「速率」，按單位時間量測（每秒請求數、每秒位元組數，也叫帶寬）。它們不是彼此的倒數，而且以微妙的方式相互權衡。批次與管線化（pipelining）藉由把固定成本攤到許多項目上來提高吞吐，但它們加入了等待，因而提高延遲。反過來，每個請求一到就立刻處理能保持低延遲，卻可能浪費容量。在負載下它們之間的關係由 Little 法則刻畫：在途請求的平均數量等於吞吐量乘以延遲（L = 吞吐量 x 延遲）。一個推論是：當你把吞吐量推向系統的極限，佇列堆積、延遲急遽上升——所以最高吞吐的工作點通常延遲很糟，於是你刻意跑在尖峰之下以保持延遲可接受。

它之所以重要，是因為選錯目標會浪費力氣，還可能讓使用者痛苦。一個批次分析工作在意吞吐（在早晨前把整晚的資料跑完），而幾乎不在意任何單筆紀錄的延遲；一個互動式編輯器在意延遲（按鍵到畫面必須感覺瞬間），遠勝過總吞吐。誠實的提醒：別把它們塌縮成單一的「速度」數字。一個讓吞吐加倍卻把尾端延遲變成三倍的改動，對一種工作負載是明顯的勝利、對另一種是明顯的失敗——開始之前先說清楚你要最佳化哪個指標，並盯著另一個，免得你無聲地把它弄垮。