天天看點

【Base】如何了解Latency和Throughput: 吞吐量和延遲

Date: 2018.6.13

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.

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

繼續閱讀