如何理解Latency和Throughput: 吞吐量和延遲

 Latency，中文譯作延遲。Throughput，中文譯作吞吐量。它們是衡量軟體系統的最常見的兩個指標。

    延遲一般包括單向延遲（One-way Latency）和往返延遲（Round Trip Latency），實際測量時一般取往返延遲。它的單位一般是ms、s、min、h等。

    而吞吐量一般指相當一段時間內測量出來的系統單位時間處理的任務數或事務數（TPS）。注意“相當一段時間”，不是幾秒，而可能是十幾分鍾、半個小時、一天、幾周甚至幾月。它的單位一般是TPS、每單位時間寫入磁碟的位元組數等。

    思考一個問題：

低延遲一定意味著高吞吐量嗎？如果不是，試舉出反例。

    假如有一個網站系統，客戶端每次請求網站服務端，網路傳輸時間（包括往返）為 200ms，服務端處理請求為10ms。那麼如果是同步請求，則延遲為210ms。此時如果提高網路傳輸速度，比如提高到100ms，那麼延遲為110ms。這種情況減少延遲似乎確實可以一定程度提高吞吐量，原因主要在於：系統性能瓶頸不在於服務端處理速度，而在於網路傳輸速度。

    繼續假設將同步請求改為非同步請求，那麼現在延遲為100ms，延遲降低了，但吞吐量保持不變。所以這是一個反例。

    除了上面這個反例外，還有一個更生動的反例：

火車、飛機運煤：從山西到廣州運煤，一列火車100小時（包括往返）可以運輸10000t煤，而一架飛機20小時（包括往返）可以運輸100t煤

 顯然飛機運煤的延遲明顯低於火車運煤，但如果測試運10000t煤，則火車運煤的吞吐量遠高於飛機：

• 火車運煤的吞吐量為100t/小時
• 飛機運煤的吞吐量為5t/小時

    我們可以將上面的運煤場景類比軟體系統，火車、飛機運煤可以比作Web伺服器處理請求，比如Apache和Nginx。在併發請求數不高時，比如10000（我假設的）以下時，也許Apache的吞吐量可能優於Nginx，但在大於10000時Apache的吞吐量就開始急劇下降，而Nginx的吞吐量相對之前比較穩定。所以比較Web伺服器的吞吐量時，必須觀察在併發請求數逐漸遞增情況下它們各自的表現。

    根據延遲和吞吐量我們還可以計算併發度（Concurrency），公式如下：

　　併發度　= 吞吐量 * 延遲

比如一個任務的處理花費1ms，吞吐量為1000tps，那麼併發度就等於1/1000*1000=1，可以得出任務處理執行緒模型是單執行緒模型。

又比如一個HDD磁碟的延遲為8ms，但吞吐量可以達到每秒鐘寫40MB，那麼每次磁碟尋道可以寫入的資料量為(40*10^6) * (8*10^-3)B = 320,000B = 320KB。 

吞吐量和延遲

下面的比喻是關於吞吐量（throughput）和延遲（latency）的。如果你要搞網路效能優化，這兩個概念是你必須要知道的，它們看似簡單實則不是。我相信包括我在內的很多人都曾經認為大的吞吐量就意味著低延遲，高延遲就意味著吞吐量變小。下面的比喻可以解釋這種觀點根本不對。該比喻來自這裡，我來做個大體意譯（非逐字翻譯）。

我們可以把網路傳送資料包比喻成去街邊的 ATM 取錢。每一個人從開始使用 ATM 到取錢結束整個過程都需要一分鐘，所以這裡的延遲是60秒，那吞吐量呢？當然是 1/60 人/秒。現在銀行升級了他們的 ATM 機作業系統，每個人只要30秒就可以完成取款了！延遲是 30秒，吞吐量是 1/30 人/秒。很好理解，可是前面的問題依然存在對不對？別慌，看下面。

因為這附近來取錢的人比較多，現在銀行決定在這裡增加一臺 ATM 機，一共有兩臺 ATM 機了。現在，一分鐘可以讓4個人完成取錢了，雖然你去排隊取錢時在 ATM 機前還是要用 30 秒！也就是說，延遲沒有變，但吞吐量增大了！可見，吞吐量可以不用通過減小延遲來提高。

好了，現在銀行為了改進服務又做出了一個新的決定：每個來取錢的客戶在取完錢之後必須在旁邊填寫一個調查問卷，用時也是30秒。那麼，現在你去取錢的話從開始使用 ATM 到完成調查問卷離開的時間又是 60 秒了！換句話說，延遲是60秒。而吞吐量根本沒變！一分鐘之內還是可以進來4個人！可見，延遲增加了，而吞吐量沒有變。

從這個比喻中我們可以看出，延遲測量的是每個客戶（每個應用程式）感受到的時間長短，而吞吐量測量的是整個銀行（整個作業系統）的處理效率，是兩個完全不同的概念。用作者的原話說是：

In short, the throughput is a function of how many stages are in parallel while latency is a function of how many are in series when there are multiple stages in the processing. The stage with the lowest throughput determines the overall throughput.

正如銀行為了讓客戶滿意不光要提高自身的辦事效率外，還要儘量縮短客戶在銀行辦事所花的時間一樣，作業系統不光要儘量讓網路吞吐量大，而且還要讓每個應用程式傳送資料的延遲儘量小。這是兩個不同的目標。

 Latency，中文譯作延遲。Throughput，中文譯作吞吐量。它們是衡量軟體系統的最常見的兩個指標。

    延遲一般包括單向延遲（One-way Latency）和往返延遲（Round Trip Latency），實際測量時一般取往返延遲。它的單位一般是ms、s、min、h等。

    而吞吐量一般指相當一段時間內測量出來的系統單位時間處理的任務數或事務數（TPS）。注意“相當一段時間”，不是幾秒，而可能是十幾分鍾、半個小時、一天、幾周甚至幾月。它的單位一般是TPS、每單位時間寫入磁碟的位元組數等。

    思考一個問題：

低延遲一定意味著高吞吐量嗎？如果不是，試舉出反例。

    假如有一個網站系統，客戶端每次請求網站服務端，網路傳輸時間（包括往返）為 200ms，服務端處理請求為10ms。那麼如果是同步請求，則延遲為210ms。此時如果提高網路傳輸速度，比如提高到100ms，那麼延遲為110ms。這種情況減少延遲似乎確實可以一定程度提高吞吐量，原因主要在於：系統性能瓶頸不在於服務端處理速度，而在於網路傳輸速度。

    繼續假設將同步請求改為非同步請求，那麼現在延遲為100ms，延遲降低了，但吞吐量保持不變。所以這是一個反例。

    除了上面這個反例外，還有一個更生動的反例：

火車、飛機運煤：從山西到廣州運煤，一列火車100小時（包括往返）可以運輸10000t煤，而一架飛機20小時（包括往返）可以運輸100t煤

 顯然飛機運煤的延遲明顯低於火車運煤，但如果測試運10000t煤，則火車運煤的吞吐量遠高於飛機：

• 火車運煤的吞吐量為100t/小時
• 飛機運煤的吞吐量為5t/小時

    我們可以將上面的運煤場景類比軟體系統，火車、飛機運煤可以比作Web伺服器處理請求，比如Apache和Nginx。在併發請求數不高時，比如10000（我假設的）以下時，也許Apache的吞吐量可能優於Nginx，但在大於10000時Apache的吞吐量就開始急劇下降，而Nginx的吞吐量相對之前比較穩定。所以比較Web伺服器的吞吐量時，必須觀察在併發請求數逐漸遞增情況下它們各自的表現。

    根據延遲和吞吐量我們還可以計算併發度（Concurrency），公式如下：

　　併發度　= 吞吐量 * 延遲

比如一個任務的處理花費1ms，吞吐量為1000tps，那麼併發度就等於1/1000*1000=1，可以得出任務處理執行緒模型是單執行緒模型。

又比如一個HDD磁碟的延遲為8ms，但吞吐量可以達到每秒鐘寫40MB，那麼每次磁碟尋道可以寫入的資料量為(40*10^6) * (8*10^-3)B = 320,000B = 320KB。 

吞吐量和延遲

下面的比喻是關於吞吐量（throughput）和延遲（latency）的。如果你要搞網路效能優化，這兩個概念是你必須要知道的，它們看似簡單實則不是。我相信包括我在內的很多人都曾經認為大的吞吐量就意味著低延遲，高延遲就意味著吞吐量變小。下面的比喻可以解釋這種觀點根本不對。該比喻來自這裡，我來做個大體意譯（非逐字翻譯）。

我們可以把網路傳送資料包比喻成去街邊的 ATM 取錢。每一個人從開始使用 ATM 到取錢結束整個過程都需要一分鐘，所以這裡的延遲是60秒，那吞吐量呢？當然是 1/60 人/秒。現在銀行升級了他們的 ATM 機作業系統，每個人只要30秒就可以完成取款了！延遲是 30秒，吞吐量是 1/30 人/秒。很好理解，可是前面的問題依然存在對不對？別慌，看下面。

因為這附近來取錢的人比較多，現在銀行決定在這裡增加一臺 ATM 機，一共有兩臺 ATM 機了。現在，一分鐘可以讓4個人完成取錢了，雖然你去排隊取錢時在 ATM 機前還是要用 30 秒！也就是說，延遲沒有變，但吞吐量增大了！可見，吞吐量可以不用通過減小延遲來提高。

好了，現在銀行為了改進服務又做出了一個新的決定：每個來取錢的客戶在取完錢之後必須在旁邊填寫一個調查問卷，用時也是30秒。那麼，現在你去取錢的話從開始使用 ATM 到完成調查問卷離開的時間又是 60 秒了！換句話說，延遲是60秒。而吞吐量根本沒變！一分鐘之內還是可以進來4個人！可見，延遲增加了，而吞吐量沒有變。

從這個比喻中我們可以看出，延遲測量的是每個客戶（每個應用程式）感受到的時間長短，而吞吐量測量的是整個銀行（整個作業系統）的處理效率，是兩個完全不同的概念。用作者的原話說是：

In short, the throughput is a function of how many stages are in parallel while latency is a function of how many are in series when there are multiple stages in the processing. The stage with the lowest throughput determines the overall throughput.

正如銀行為了讓客戶滿意不光要提高自身的辦事效率外，還要儘量縮短客戶在銀行辦事所花的時間一樣，作業系統不光要儘量讓網路吞吐量大，而且還要讓每個應用程式傳送資料的延遲儘量小。這是兩個不同的目標。