歡迎光臨
每天分享高質量文章

低延遲 Java(1):介紹

本文是 Java 低延遲程式設計系列文章的第一篇。讀完本文,您將掌握以下概念:

 

  • 什麼是延遲,作為開發者為什麼要關心延遲?
  • 如何描述延遲,資料中的百分比意味著什麼?
  • 什麼因素會造成延遲?

 

閑話少說,讓我們開始吧。

 

1. 什麼是延遲,為什麼延遲很重要?

 

延遲可以簡單定義為執行一個操作耗費的時間。

 

“操作(operation)”是一種寬泛的說法,在這裡我指的是軟體系統中值得測量的行為,以及某個時間點該行為的一次執行過程。

 

例如,在典型 Web 應用中,操作可以是從瀏覽器提交查詢並檢視搜尋結果;在交易應用程式中,可以是金融交易工具收到價格變動後自動向交易所傳送買入賣出指令。通常,操作花費的時間越短,對使用者的好處越大。使用者更喜歡那些不需要等待的網路應用。回想當初,谷歌比同時代其他搜尋引擎最大的優勢就是快速搜尋體驗。交易系統對市場變化的反應越快,交易成功的機率就越高。數以百計的交易公司沉迷於讓他們的交易引擎成為華爾街上延遲最低的系統,並因此從中獲得競爭優勢。

 

不誇張地說,在高風險的地方,降低延遲可以決定一家企業的成敗!

 

2. 如何描述延遲?

 

每個操作都有延遲,一百種操作有一百種延遲。因此,不能使用像“運算元/秒”或“秒數/操作”這種單一的指標描述系統延遲,因為這隻能用於描述某種操作的單次執行。

 

乍一看,可以把延遲定義為所有同類操作的平均值。這可不是什麼好主意。

 

取平均值有什麼問題嗎?請考慮下麵這張圖:

 

 

有幾個操作度超過了60毫秒的 SLA 標的(實際上是7個),但平均響應時間卻位於 SLA 範圍內。一旦採用平均響應時間,紅色區域內的所有異常值都會被忽略。然而,忽略的這部分異常值恰恰是對軟體工程師來說最重要的資料,即需要關註和梳理的系統效能問題。更糟糕的是,隱藏在這些資料背後的問題在實際生產環境中往往會發生。

 

另外值得註意的是,實際上很多延遲測量結果可能會像上圖看到的那樣,偶爾會看到一些隨機的嚴重異常值。延遲從來不遵循正常分佈、高斯分佈或者泊松分佈,你看到更多的可能是多重模態分佈延遲。實際上,這就是為什麼用平均值或標準差來討論延遲是無效的。

 

延遲最好用百分比描述。

 

什麼是百分位數?考慮一組數字,第 n 個百分位數(其中 `0 < n < 100`)將其分為兩個部分,較低的部分包含 n% 的資料,較高的部分包含 (100 – n)% 的資料。因此,這兩部分的資料總和為 100%。

 

例如,50%是指一半低於50%,另一半高於50%。百分比更廣為人知的說法是中位數。

 

讓我們舉幾個測量延遲的例子。90%的延遲為75毫秒,意味著100個操作中有90個操作延遲最多為75毫秒,而其餘的操作,即100 – 90 = 10,延遲至少為75毫秒。

 

如果進一步補充,98%延遲170毫秒,這意味著100個操作中有2個操作的延遲達到或超過170毫秒。

 

如果再進一步補充,99%延遲313毫秒,這意味著每100個操作中有1個操作與其他操作相比有更大的延遲。

 

事實上,許多系統表現出這樣的特徵,即使百分比增加延遲也會顯著增長。

 

 

 

為什麼要擔心長尾延遲呢?我的意思是,如果每100個操作中只有1個操作有較高延遲,那麼系統效能還不夠好嗎?

 

好吧,為了有一個直觀的印象,請想象下麵這個場景。一個熱門網站,90%延遲1秒、95%延遲2秒、99%延遲25秒。假設網站所有頁面日瀏覽量超過100萬,也就是說某個頁面會有超過10000次載入超過25秒。這時候使用者可能會打著哈欠關閉瀏覽器轉而去乾別的事情,更糟糕的情況他們會向親朋好友吐槽這次糟糕的體驗。任何線上業務都負擔不起這樣的長尾延遲。

 

3. 導致延遲的原因是什麼?

 

最簡短的回答是:一切皆有可能!

 

延遲“抖動”會產生特有形狀、出現隨機離群值,可歸因於下麵這些事情:

 

  • 硬體中斷
  • 網路/IO延遲
  • 管理程式暫停
  • 作業系統活動,例如內部結構重建、掃清緩衝等
  • 背景關係切換
  • 垃圾收集暫停

 

這些事件通常是隨機的,並不遵循正態分佈。

 

另外,從更高的層次來看 Java 程式執行:

 

 

(管理程式、容器對於裸機硬體是可選的,但在虛擬化或雲環境中與延遲密切相關)

 

減少延遲與以下因素密切相關:

 

  • CPU/快取/記憶體架構
  • JVM 架構和設計
  • 應用程式設計:併發、資料結構演演算法和快取
  • 網路協議等

 

上面的圖中每一層都很複雜,大大增加了效能最佳化所需的知識和專業技能,也是時刻需要考慮成本、時間合理性的原因。

 

但這就是效能工程如此有趣的原因!

 

我們的挑戰是,讓應用對所需的每一次操作執行延遲總是保持在合理的較低水平。

 

說起來容易,做起來難!

 

感謝閱讀!

    贊(0)

    分享創造快樂