美團性能優化之路——性能指標體系

前言

在互聯網網站百花齊放的今天，網站響應速度是用戶體驗的第一要素，其重要性不言而喻，這裏有幾個關於響應時間的重要條件：

• 用戶在瀏覽網頁時，不會注意到少於0.1秒的延遲；
• 少於1秒的延遲不會中斷用戶的正常思惟， 可是一些延遲會被用戶注意到；
• 延遲時間少於10秒，用戶會繼續等待響應；
• 延遲時間超過10秒後，用戶將會放棄並開始其餘操做；

而在美團，「消費者第一」是公司的第一價值觀，爲了給消費者提供更好的用戶體驗，美團網的技術Geeker們在性能優化的路上作了很多的工做，開發了許多工具讓網站的性能監測更容易，經過各類可視化報表，工程師們只須要點點鼠標就能看到網站的性能數據，並能根據數據來預測系統的性能趨勢，快速發現有價值的優化點。在本文中，不講best practices，也不去講具體的優化手段，僅從美團平常通用的性能指標體系的角度去分享美團的實踐。

性能指標的分類

爲了更好的去監控整個系統的性能，作好全流程的優化，美團將指標分爲了如下3類：

• Perceived system performance:這類指標主要從工程師的角度去衡量，如後端的響應時間，當前併發的用戶數，請求數，請求的錯誤率等等。
• Perceived user experience:這類指標用來衡量⽤戶的真實體驗，從用戶體驗的角度出發，如首屏時間，白屏時間，徹底加載時間之類，即用戶能實際感受到得網頁加載延遲。
• System performance:這類指標從服務器的角度出發，監測目前服務器的cpu，內存，網絡帶寬,流量等等物理資源。

對於上述的每一類，衡量標準可能都不同，在數據展現方面，主要經過趨勢圖和彙總表格來展示，下面來對這3類指標分別細說：

##Perceived system performance

這類指標主要爲工程師設計，來衡量業務後端的處理速度，主要從如下幾個方面去衡量：

1) 響應時間 在美團，響應時間是性能的主要kpi，對於響應時間，美團作了不少精細化的處理； 首先對每一個業務的總體(集羣)響應時間有個衡量：

• 95%的響應時間：將一段時間內全部請求的響應時間中取一個值，使95%的請求響應時間均小於或等於它，此值即爲95%請求覆蓋的響應時間。
• 90%的響應時間：將一段時間內全部請求的響應時間中取一個值，使90%的請求響應時間均小於或等於它，此值即爲90%請求覆蓋的響應時間。
• 50%的響應時間：將一段時間內全部請求的響應時間中取一個值，使50%的請求響應時間均小於或等於它，此值即爲50%請求覆蓋的響應時間。

以某內部服務爲例，3條不一樣的曲線分別表明了3種不一樣的響應時間維度： 

另外爲了方便工程師的優化，對具體到每一個請求url都作了更精細化的統計，不光統計了上述的指標，還增長了：

• 最大響應時間：某請求的某段時間範圍內響應時間的最大值。
• 最小響應時間: 某請求的某段時間範圍內響應時間的最小值。
• 時間標準差：某請求某段時間範圍內的波動狀況，用來衡量某請求是否存在很大波動，標準差越大，波動越大。

以某內部服務爲例，經過彙總表格展示出某小時的某url的更細響應時間的維度： 

2）請求數（按天或小時統計）

根據不一樣的時間維度去統計系統天天或每小時的請求數（每小時的統計狀況能夠見上圖），並以趨勢圖和表格形式展現。

某內部服務天天請求數的趨勢圖： 

3）錯誤率 關於錯誤率的統計主要有如下幾種：

• connection timeout:http請求中出現504的次數和比例。
• error response：http請求中出現500的次數和比例。
• 錯誤網關數：http請求中出現502的次數和比例。
• 異常日誌統計:統計業務中出現得異常的數量和趨勢。

以某內部服務的異常數量趨勢爲例： 

##Perceived user experience

這類指標從用戶的角度出發，經過模擬用戶請求或對真實用戶抽樣，來監控用戶對網站的實際體驗效果，主要利用js來收集不一樣瀏覽器下訪問網站的加載速度和性能；對於一次完整用戶請求來講，http請求能夠劃分爲以下幾個階段：

• DNS：域名解析階段，一般在幾毫秒左右
• TCP：創建網絡鏈接
• Requesting：發送請求
• WebServer處理
• Transferring：傳輸數據
• Parsing：瀏覽器解析。幾個重要的時間點爲： a. 首屏時間 客戶端第一屏資源加載完畢 b. domready時間 DOM解析完畢，能夠進行動態修改 c. load時間 全部資源加載完畢

對於上述的幾個階段，咱們設立了多種時間參數（每一個參數又有 90% 和 50% 兩種指標）來衡量，具體以下：

• 查找域名：開始查找域名到查找結束,計算公式爲（domainLookupEnd - domainLookupStart）
• 創建鏈接：開始發出鏈接請求到鏈接成功,計算公式爲（connectEnd - connectStart）
• 請求文檔：開始請求文檔到開始接收文檔,計算公式爲（responseStart - requestStart）
• 接收文檔：開始接收文檔到文檔接收完成,計算公式爲（responseEnd - responseStart）
• domready：開始解析文檔到 DOMContentLoaded 事件被觸發,計算公式爲（domContentLoadedEventStart - domLoading）
• load事件持續：load 事件被觸發到 load 事件完成,計算公式爲（loadEventEnd - loadEventStart）
• 徹底加載：開始解析文檔到文檔徹底加載,計算公式爲（domComplete - domLoading）
• 首屏加載：開始解析文檔到首屏加載完畢,計算公式爲（firstscreenready - domLoading）
• 徹底加載【全過程】：這次瀏覽最開始時刻到徹底加載完畢,計算公式爲（domComplete - navigationStart）
• 首屏加載【全過程】：這次瀏覽最開始時刻到首屏加載完畢,計算公式爲（firstscreenready - navigationStart）

爲了更清楚的說明每一個參數的意義，用下圖說明以下： 

其中不一樣的指標對於用戶體驗的影響權重不一樣，對於用戶來講白屏時間（瀏覽最開始時刻到首屏加載前）和首屏時間是最重要的。

某應用的上述時間參數趨勢圖：

##System performance

這類指標主要監測目前服務器的cpu，內存，硬盤io率，網絡帶寬,流量等等物理資源的使用狀況，這類指標比較常見，就不細說了。

某內部服務的cpu使用率狀況：

某內部服務的硬盤io狀況： 

某內部服務的網絡io狀況： 

#總結 俗話說「軍馬未動，糧草先行！」，監控->分析->優化，號稱是性能優化的三部曲，爲了更容易地找到性能優化的關鍵點，創建一個統一的精細化的性能監控平臺，作到數據驅動型的性能優化，是公司的長遠目標，也是值得公司投入的一個方向，性能優化，從監控開始，只有監控的性能指標體系創建好了，才能更好地去作分析和優化！