攜程網實踐案例分享：利用HTML5監控網站性能

仲介交易 SEO診斷 淘寶客 雲主機 技術大廳

文 / 儲誠棟，劉海峰，謝生校

HTML5技術給Web帶來很多新的元素，不僅使網站變得越來越美觀，交互體驗越來越接近完美，更使得很多曾經不可能完成的功能都可以實現。 本文針對HTML5在網站性能監控方面帶來的新特性，與大家分享攜程旅行網在此方向的實踐經驗。

網站性能監控的現狀

網站性能越來越被大眾所關注，因為它直接影響使用者體 驗。 大多數互聯網公司在網站性能監控方面僅做到伺服器性能監控和網路I/O監控，這樣的背景催生了一些協力廠商做網站性能監控的公司，如基調、監控寶、GA 等。 它們都有一個共同點——基本在全國主要城市鋪設了監控點，定時主動訪問頁面來獲取效能資料。 然後定時對資料進行匯總，生成報表後提供給最終使用者。

協力廠商監控的優勢與劣勢

協力廠商監控有如下一些優勢與劣勢。

優勢

無需改動現有程式碼。 協力廠商監控由於採用主動訪問並採集的機制，只需要在使用者管理介面配置相關頁面的URL，就可以類比使用者訪問的過程，因而完全不需要開發人員介入。

能採集到豐富的資料。 因為類比訪問使用的瀏覽器由供應商部署，所以可以在用戶端加入自訂外掛程式或集成其他性能工具，能通過程式設計實現各類效能資料的採集。

資料量不大，匯總方便。 這取決於供應商的監測點部署，但限於成本考慮，一般供應商只會在一二線城市部署，這樣資料量匯總相對容易，分析複雜度較低。

出現問題時可重現和驗證。 因為能有豐富的資料，並且發生問題的監測點可控，我們就能很容易重現，方便排錯。

劣勢

一次性投入大。 監測點的部署需要大量設備支援，如果只是為一家公司提供服務，性價比不高，需要大量的資金。

難以完成不同瀏覽器下的測試。 監測點無法顧及到所有使用者使用的瀏覽器，對於不同的業務，客戶群體不一致，瀏覽器的權重也不同，故監測點一般以IE和WebKit核心的瀏覽器為主。

回應有時間間隔。 一般來說，監控頁面不可能只有一個，會有很多，測試時為保證不互相干擾，特別是效能測試，會依次按佇列方式進行，這會使得一個迴圈的時間很長，且需要等到所有監測點均完成測試後方可獲得最終報告，不能及時反映當前的狀態。

對於強依賴流程進入的頁面難以監控。 例如預訂流程，需要POST大量資訊，且有時效性，對於監測點來說具有一定的挑戰。 現在有些運營商可以提供一些簡單的腳本功能，但對於日益複雜的業務需求，已無法滿足。

監控點有限，不能覆蓋整體使用者群。 監控點可以增加，但總是無法覆蓋所有的網路環境，因此資料只能用於參考，並不能代表真實使用者感受。

HTML5給我們帶來了什麼

HTML5中新加入的performance標準在IE9、最新的Firefox和Chrome中都已實現，精確度也達到了毫秒級別，通過詳細時間點，我們能獲得很多關鍵的指標項。

在此，我們簡單看一下一些可用的指標(如圖1)。 其中有很多能説明我們瞭解用戶端性能和客戶感受，例如：伺服器端處理時間 + 網路傳輸時間(較短)=responseStart–requestStart，用戶端白屏時間=domInteractive– navigationStart或responseStart等。

圖1 HTML5性能指標(圖片引用自W3C官方網站)

對於攜程，我們最主要監控的指標有下面幾種。

1. Total總時長：從頁面跳轉開始至頁面onLoad;

2. DNS功能變數名稱解析時長：從發起頁面功能變數名稱解析至解析完成;

3. Connect建立與伺服器TCP連接時長：從發起TCP連接至三向交握完成;

4. Request請求時長：從發起頁面請求至伺服器端返回第一個位元組;

5. Response回應時長：從接收伺服器發回的第一位元組至主頁面下載完成;

6. DomReady頁面Dom樹解析：從頁面跳轉至頁面Dom元素穩定。

接下來我們看看用戶端資料獲取的優勢與劣勢。

優勢

真實的客戶訪問效能資料。 客戶在訪問網站的同時，可能還在做很多其他操作，並且可能還有很多其他的網路應用佔用頻寬，真實的使用者資料對於瞭解客人感受具有代表性。

能區分瀏覽器、作業系統平臺。 時下，使用者使用著各種各樣的外殼瀏覽器和自訂瀏覽器，而普通的測試無法覆蓋到如此複雜的網站流覽環境，因此這部分資料尤其珍貴。

覆蓋範圍廣，且地域分佈較均衡。 相比協力廠商，我們能依靠JavaScript收集到各個地域的資料，甚至是海外，規模越大的網站，越有意義，能反映使用者當地的網路狀況，獲知CDN加速效果等。

瀏覽器原生支援，精度高。 毫秒級的精度對於網路DNS、Connect時間，以及瀏覽器初始化事件執行時間有很大的意義。

劣勢

對於舊版本瀏覽器無能為力。 效能資料採集需要HTML5的支援，對於IE6、IE7、IE8，不支援這一標準是其最大硬傷，不過得益于HTML5的推進速度，隨著高版本瀏覽器的發佈，這個問題會逐漸淡化，並不需要我們操心。

需要部署少量JavaScript代碼。 類似于Google Analyze的代碼載入機制，需要在每個頁面的底部嵌入代碼，工作量取決於網站架構，如果有統一的頁腳，工作量其實很小。

無法重現。 由於資料來自客戶，當時的狀態無法保留，很難類比客戶的環境，會對於排錯有一定的影響。

攜程網的最佳實踐

攜程在資料獲取方面已累積了一定經驗，主要實現思路與環境搭建如圖2所示。

圖2 主要的實現思路與環境搭建

JavaScript 採集 / 資料回發

當 頁面載入完成後，部署在頁面中的JavaScript代碼會從performance.timing物件中獲取性能資訊，然後把這些資料拼裝成URL參 數，類比發送一個圖片請求到Collector伺服器。 類比圖片請求的方式和Google Analyze等相似，即new Image().src=。 這種方式應用廣泛，具有跨域、相容性好等優點。

這種回傳方式也有不足。 眾所周知，GET請求的參數長度是有限制的，這意味著我們必需小心處理回發資料的長度，對於超長的資訊進行截斷。 如若不然，過長的資訊有可能會被直接丟掉，不利於後續的處理與分析。

Nginx 接收 / 記錄Log

Collector 服務是由性能卓越的Nginx集群來擔任的。 為了最大程度降低用戶端回傳資料時的資源佔用，Nginx採取只記日誌，不做任何處理的辦法。 這樣用戶端回傳 資料可以快速完成並關閉連接，使之對使用者體驗的影響降至最小。 而Nginx(包括Apache等)的常用訪問日誌格式中都含有GET請求的完整URL，我 們回傳的效能資料就記錄在URL的參數中。

為了優化Collector集群的負載能力，我們需要對Linux、Nginx等做相應的調優。

Linux 方面，最大打開檔數是最關鍵的一個參數。 由於常規Web伺服器往往運行著PHP、JavaScript等動態腳本，每個請求還涉及資料庫操作，它們的並 發能力到1000就不錯了。 Linux伺服器預設配置通常足以滿足這個級別的併發數。 但我們的場景比較特殊：我們幾乎不需要做處理，只記下訪問日誌即可。 Nginx伺服器以併發性能強著稱，官方資料表示可以支援10萬併發。 在Linux系統中，每一個連接，對應的就有一個Socket檔，因此最大併發數 受制于系統對最大打開檔數的限制。 除此之外，還有一些網路相關的內核參數也根據應用場景進行了優化。

Nginx方面，去除了不需要的功能，保留了HttpEmptyGifModule。 這個模組對到來的請求僅返回一個1×1圖元的GIF圖片。 由於圖片資料只有幾個位元組，直接保持在記憶體中，所以它可以以極快的速度對用戶端請求做出回應。

location = /_.gif { empty_gif;}

如上配置的效果是，訪問HTTP://yourdomain/_.gif將得到一個只有一圖元的GIF圖片，其回應速度非常快。

讀取 Log / 發送至佇列

一 個專門負責記錄傳送的Agent會通過類似tail的機制跟蹤日誌內容，即時地將新增日誌條目發送至訊息佇列，以備後續處理。 這部分的意義在於：第一，它 將集群中分散的日誌統一發送到了一處，是一個日誌的聚合過程;第二，將分析程式與Nginx伺服器解耦開來，最大化保障Nginx集群的高可用性，也最大 化保障了RAW Data的可用性。

從佇列中取出 / Storm集群即時分析

後端資料分析程式採用了分散式即時流資料處理框架Storm。 基於該框架進行處理，一來面對搜集到的海量資料，可以橫向擴展處理能力，二來即時流式的運算延遲很小，可以即時獲取頁面性能資訊，使及時的預警成為可能。

Storm把資料處理抽象成由一個個邏輯單元組成的拓撲結構(如圖3)。 每個邏輯單元由運算和輸入輸出組成，按照Storm的術語，這些邏輯單元有兩大類：Spout和Bolt，其中Spout是資料的源頭。

圖3 Storm運算拓撲結構示意圖(引用自Storm官方網站)

這些拓撲結構，將被分散到集群中的各個物理節點上，從而進行分散式的高效運算，可以迅速處理大量資料。

我們在Storm集群上所做的事情，包括瀏覽器、作業系統、地理位置等的分析，分析後的資料，直接支援按地區、運營商、系統平臺、瀏覽器類型，以及指定具體的頁面等條件任意查詢和報表。

產生即時報表 / 預警郵件 / 預警短信

借助于Storm框架的強大即時處理能力，對日誌的分析可以迅速產生即時報表。 此外通過與歷史資料的參照對比，還可以就效能資料中的異常資訊給予預警，包括發送預警郵件和預警短信等。

即時報表直接在記憶體中處理，借助Storm的DRPC(Distributed Remote Procedure Call)(如圖4)，也即分散式遠程序呼叫，可以把緩存在各個運算節點中的最近資料直接聚合起來生成報表。

圖4 Storm Distributed RPC示意圖(引用自Storm官方網站)

通過一些規則判斷，我們對即時資料流進行一些預警操作。 預警事件觸發後，相關資訊作為一個事件發往報警系統。 報警系統根據配置，向相關人員發送預警郵件或短信。

日、周、季、年匯總

在Storm輸出資料的基礎上，定時按日、周、季、年進行匯總。 對於匯總資料可以方便地進行歷史資料查詢，為即時預警、長期性能評估等提供參考。 同時以不同細微性進行舊資料的匯總，可以逐步丟棄過時的龐大詳細資料，減輕資料庫的壓力。

還有什麼我們可以做的?

整個環境搭建需要不少的人力物力，很多人可能會對其價值懷疑。 在這裡，我想告訴大家，用戶端的資料收集是非常值得投入的。 除了以上提到的頁面訪問的時間點資料獲取外，其實我們還有很多地方可以複用。

例如用戶端的JavaScript錯誤採集，使用try catch和onerror的組合，收集用戶端的錯誤資訊。 在攜程，我們也把這類資料歸為網站的效能資料，JavaScript錯誤會直接影響使用者對網站 的印象，同時會影響使用者在網站的消費，直接關係到利潤，不可忽視。

又例如，通過使用者行為資料獲取，可以獲得頁面的基本訪問資訊。 使用者訪問流、使用者在頁面上的所有操作，都可以説明改進現有產品，如果條件允許，配合A/B測試，對於新產品的研發也能提供很多有價值的參考。

因此，大家可以憑藉想像力，擴展思路，獲得更多有意義的資訊，完成更多有意義的研究。

(本文三位作者均來自攜程旅行網)

本文選自《程式師》雜誌2013年1期，未經允許不得轉載。 如需轉載請聯繫 market@csdn.net