理解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。 

參考資料：

http://vanillajava.blogspot.com/2012/04/what-is-latency-throughput-and-degree.html

http://queue.acm.org/detail.cfm?id=1854041