了解延遲（latency）和吞吐量(throghtput)

轉載自：http://my.oschina.net/feichexia/blog/215649

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

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

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

    思考一個問題：

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

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

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

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

?

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

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

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

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

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

?

1	并發度 = 吞吐量 * 延遲

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

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