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