321
【AliExpress】大數據驅動性能優化
該文章來自阿裏巴巴技術協會（ATA）
本文示例以PC的優化端為例，目前AE在這塊的工作還主要在PC端，但文中的方法對無線端完全適用
1. 概念
1.1 什麼是大數據驅動性能優化？
性能優化其實就是用各種可行的優化手段**降低頁麵Latency，從而提升用戶體驗**。通常會遇到如下困難：
Latency降低了，真的提升了用戶體驗嗎？ 在AE的性能優化的灰度實驗中，遇到了性能提升，轉化率反而下降的情況，最後大家勐然醒悟，如果我的優化根本就是用戶不可見的呢？比如減少了某個異步資源的加載，這個異步加載會降低pageload，但它可能就是一個用於統計的數據打點JS，加載了這個資源所耗時間並沒有體現在用戶的感觀上。更極端一點說，Latency降低了，但這個降低引入了部分用戶JS錯誤，甚至BLOCK了用戶的下一步動作？可以通過大數據的方法識別出這樣的問題。詳見2.3。
Latency降低了，用戶體驗也提升了，但這個優化的投入**成本較大，我是否應該投入？** 。通過度量大數據與業務轉化的關係，可以精確量化性能優化所能帶來的業務指標提升，從而精確計算性能優化的投入產出，也就容易判斷是否值得投入。
以上講述了通過大數據手段識別問題；度量投入產出；並且最終Review投入產出，給未來的性能優化提供知識和經驗。
但事後對結果進行Review並沒有體現出大數據的真正魅力，大數據的魅力在於把它在線應用起來，通過大數據結合算法對用戶的場景和行為進行識別和預測，基於這個結果在線差異化優化性能，如預測用戶的對下一個頁麵點擊的可能性，從而在CDN中預先加載下一個頁麵的資源，提升性能和用戶體驗。
綜上，大數據驅動性能優化是指運用大數據度量性能，以及基於大數據優化性能。
1.2 如何構建大數據驅動性能優化
1.2.1 如何運用大數據度量性能？
A. 找出接近用戶感受的性能指標
頁麵的展現過程從DNS Lookup到頁麵的Fully Load，經曆了很多步驟，這個步驟中有很多精細的度量指標。
對於用戶來講，最重要的一般是StartRender(白屏時間)，FirstScreen(首屏時間)，PageLoad(頁麵加載時間)，對於AE來講，我們最關注的指標有StartRender及PageLoad。FirstScreen由於目前我們頁麵的特點及種不同終端使得這個數值目前還很難做到"準確"，因此暫時未參考。
B. 找出與性能相關的業務指標
性能不好時，用戶更可能跳失，性能好時，用戶更可能產生下一步動作。因此，通常來講，轉化率(CTR)和跳失率(Abandon Rate，或SAR)，但是並不能直接將CTR或SAR拿來計算，因為性能更容易影響用戶的是第一次訪問的時間，因此我們在度量業務貢獻時采用的是第一次訪問的PV點擊率和PV跳失率。
另外業內也有數據顯示，好的性能體驗可以提升網站的整體pv，由於pv受到太多的業務因素影響，性能可能是特別小的因素之一，因此AE還沒有對PV與性能的關係建立模型，如果哪位大神有這方麵的經驗和建議，歡迎與我們共建這塊內容。
C. 基於大數據平台建立業務指標與性能指標的關聯
通過以上找出的業務指標和性能指標，我們就可以通過某種模型來度量性能與業務的關係，從而指導性能優化的生產實踐。除了各個頁麵單一的指標外，同事提出了通過一個指標，度量全站因為性能不夠理想導致的訂單損失，目前我們叫性能損耗。性能損耗指標就是基於每一個頁麵的性能與轉化關係，並參考網站轉化漏鬥，最終計算出來的統一值。如果期望從其它業務視角看性能關係，同樣也可以基於性能與轉化關係這個基礎，來構建其它的模型。
1.2.2 如何基於大數據優化性能？
A. 深入研究各種性能優化手段
回到最根本，想要優化性能，離不開各類性能優化的手段，個人對Native一點兒不懂，PC端的性能優化手段，請見本文3.1
B. 構建大數據模型，基於此與性能優化手段相結合，優化性能
目前我們想到的有兩塊可以利用大數據模型來進行性能優化的。第一是構建用戶點擊行為模型，能較準確的預測用戶下一各可能點擊的頁麵，並對頁麵內容活資源進行預先加載，比如預測用戶在LIST中點擊下一頁的可能性，若大於90%，就將下一個頁麵的圖片預先加載到CDN的邊緣借點。
第二個是用戶網絡環境，用戶對頁麵豐富度以及漂亮程度的依賴，用戶頁麵化簡從而實現快速呈現三者與用戶轉化活流失的關係模型。從而以用戶轉化最大化為目標，對不同網絡環境的用戶，呈現不同級別的頁麵，從而通過快速的性能體驗提升轉化。在這方麵Gmail很早就上線了讓慢加載的用戶可以選擇切換 "Load Basic HTML Page..."
2. 大數據度量性能
第一章從通用概念角度講解了大數據驅動性能優化。本章講主要講解AE的工作，AE如何通過大數據度量性能，係統架構如何，等等。
2.0 係統架構
係統分為數據采集層，數據計算層，應用層三層。顧名思義，架構簡單，這裏不累述。這個係統設計和最終實現得都較通用，集團內可以輕鬆接入，接入後即可實現基於大數據的性能度量。
2.1 性能度量
2.1.1 性能分布度量
各項指標的平均值不足以描述網站的性能情況，它不夠微觀，看不到展部用戶如何，中間用戶如何，全站有多少用戶活在水深火熱中，等等。因此我們采用不同性能情況下的流量占比來度量頁麵的性能。根據業內對各指標快、較快、慢、很慢範圍的定義，我們找到各範轉內的樣本占比情況來度量性能好壞。如下圖展示了3月16日至3月23日某頁麵PageLoad各性能範圍裏麵的占比情況。
2.1.2 統一評分
如上性能分布雖然可以更真實的反映性能情況，但還是缺少一個統一的度量，統一評分就是基於分布情況，來用一個統一的加權值來反映性能分布情況。下圖中紅框裏麵的部分是指一個頁麵的一個指標的統一評分，如首頁的PageLoad分數。依次類推，下圖展示了各頁麵各指標->各頁麵->各站點->全站的展次結構中各層次的統一分數，而這個分數就來源於性能分布數據。
2.1.3 TP99，TP50，平均值
除此以上，平均值，TP50(中位數)，TP99仍然是需要重點關注的指標，我們完全不需要有了一個好的指標，就放棄其它指標，每個指標都從自己的角度出發，有很大的觀測意義。
TP99是一個尤其值得關注的指標，它一方麵代表了我們站點中性能體驗最差的一批用戶的性能情況；另一方麵在一些基礎優化時，可能隻有對尾部有價值，如DNS的全球部點，它無法提升本來就已經在Local DNS中的LOOKUP，但它不在Local DNS中的請求提升非常大，此時TP99就是度量優化效果的最合適指標之一。

2.2 業務度量
2.2.1 性能與轉化率的關係度量
2.2.2 性能損耗
性能損耗的計算方法是，假定網站核心轉化鏈路頁麵的PageLoad Latency都到3S內，則依據每個頁麵的性能與轉化率關係曲線可以得出，每個頁麵的轉化率提升多少，這個提升轉化為PV或點擊，不斷的向它的下一跳增長，最終可以得出訂單數增長，訂單數的增長比例即性能損耗。
2.3 性能評估
第1章中已經介紹，Latency的降低可能是"假象"，它甚至是引入錯誤，犧牲用戶體驗為代價的，那麼如何度量識別這樣的問題呢？如下圖所示，相同的性能區間裏麵轉化率應該是在一定時間內較穩定的，性能優化提升轉化率是因為我們上性能好的區間裏麵流量變大了。基於2.2.1介紹的性能與轉化率關係曲線，如果性能優化後，同樣性能區間的轉化率有所下降，則證明引入了問題，否則證明是一個正常的優化。在我們的實際項目中，就通過這個方法發現了問題。
3. 基於大數據優化性能
對於基於大數據優化性能目前AE還處於初級階段，隻是YY並無實施，這一章的目的除了邏輯上的完整外哈哈，另一方麵想發起更多的思考，讓更多的人一起來建設這塊內容。
3.1 性能優化手段介紹
下圖展示了從瀏覽器->網絡->IDC整個過程的優化過程，這塊不是本文重點，細節歡迎線下交流。每個負責性能優化的同學都應該有一個這樣的大圖，裏麵有所有的優化手段，基於對所有的優化手段的理解後，再基於大數據等其它手段進行性能優化，可以做到有的放矢。
3.2 資源預取
資源預取已經是一個性能優化裏麵的成熟手段，瀏覽器就支持頁麵預取，以及DNS預取等。
CDN也同樣支持預取的概念，可以把用戶需要的圖片等資源預先加載到邊緣節點(離用戶最近的節點)，我們可以利用CDN的這一特性，通過算法預估用戶最有可能點擊的下一個頁麵，可能的點擊概率如何，若大於一定值，就將下一個頁麵的資源預先加載到邊緣節點。
同樣，我們的ESI靜態資源可以放在L1上麵，點擊預測可以同樣有助於我們提升ESI的命中率。
3.3 個性化展現
基於對用戶的畫像，如國家民族，曆史的購物行為，接入的網絡環境等，可以對不同類的用戶推送不同層次的頁麵，最終達到轉化率的最大化。這個是個人認為值得去探索的一個方向，尤其是集團全球化，會麵臨各種網絡條件、種族文化的用戶，他們的網絡接入條件不同，對慢的忍耐程度也不同，試想在偏遠的非洲，他們也許不需要豐富多采的頁麵，隻需要拿著手機，訪問簡單的WAP頁麵，完成瀏覽下單就可以了。
4. 小小的總結
在大數據度量性能和基於大數據優化性能方麵，期望有同學一起參與共建，尤其是基於大數據優化性能這方麵，還有很長的路要走。
最後更新：2017-04-01 13:44:32