高流量網站如何作出高性能？

前一段時間接觸了一個教育集團的老總，集團自己是在教育實體化階段也就是各類教科書盛行的時候起來的，最近 10 年互聯網教育愈來愈火，老闆也瞅準商機跳了進來。

但是公司的在線教育板塊一直不溫不火沒有什麼轉機，Google Analytics、百度統計、CNZZ 數據專家等各類運營軟件用了個遍仍是老樣子。

**「你說爲啥？」**老總老是問身邊的人。

我嘗試打開他公司的官網以及幾個教育產品的網頁，沒有一個頁面在 10s 內被打開。。。你說爲啥？！

在時間如此精貴的當下，任何一個互聯網公司若是不注重用戶體驗，一味的注重開發、上線、銷售，其結局。。。無論大家想到沒想到，我想到了。。。。

有一種聲音老是在喊**「咱們要高性能網站！」**因而各類服務器、各類 CDN、DNS 全上了以後卻發現——花了很多效果很差。

那麼，問題來了。。。。 #####一.什麼叫高性能的網站？

現有兩個網站性能架構設計方案：方案 A 和方案 B。方案 A 在小於100個併發用戶訪問時，每一個請求的響應時間是1秒，當併發請求達到200的時候，請求的響應時間將驟增到10秒。方案 B 不論是100個仍是200個併發訪問，每一個請求的響應時間都差很少是1.5秒。

哪一個方案的性能好？

若是你的老闆要求「咱們要改善一下網站的性能」，你知道他指的是什麼嗎？

同類型的兩個網站，X 網站服務器平均每一個請求的處理時間是500毫秒，Y 網站服務器平均每一個請求的處理時間是1000毫秒，爲何用戶卻反映 Y 網站的速度快呢？

網站性能是客觀的指標，能夠具體體現到響應時間、吞吐量等技術指標；同時也是主觀的感覺，而感覺則是一種與具體參與者相關的微妙的東西，用戶的感覺和工程師的感覺不一樣，不一樣的用戶感覺也不一樣。

說的再多最後都要上生產環境，因此，最直接、最真實 的就是把用戶訪問時的各項指標做爲最終的判斷依據。

打造一個高性能的網站，首先就是要了解性能，那麼咱們就須要一些指標來具體量化前端性能這個關鍵指標！

#####二.前端頁面性能指標

1.Apdex指數

Apdex值和Apdex指數是國際通用標準，是對用戶體驗滿意度的量化值。

基於「真實用戶體驗」，Apdex 定義了 3 個用戶滿意區間：「滿意」、「可容忍」、「失望」，經過響應時間數值 「T」 來劃分。T 值表明着用戶滿意的響應時間界限，國際上通常默認爲 2s，也就是說滿意區間就是 0~2s；頁面響應時間超過 T 值用戶就有些不滿了，下一個區間「容忍」的界限值是 T 和 4T，即 4-8 秒之間爲容忍區間；響應時間再長用戶就開始考慮放棄了，最後一個區間「失望」的響應時間則大於 4T，即多於 8 秒。

採集必定時間內的 Apdex 值以後，通過計算能夠得出 Apdex 指數，具體計算公式爲:

<pre> Apdex 指數 = [ 滿意數量 + （ 可容忍數量 / 2）] / 總樣本數 </pre>

這樣，用戶訪問頁面的響應時間被量化爲一個 0 到 1 之間的「Apdex 指數」，0 表明沒有滿意用戶，1 則表明全部用戶都滿意。通過統計，基於頁面性能的 Apdex 評分於用戶的體驗緊密關聯, 爲管理、研發、運維人員提供了一種經過應用性能量化值來評估用戶滿意度的方法。

可行工具：New Relic、OneAPM Browser Insight

2.頁面響應時間

說得再好，作的再多最後頁面也是要上生產的，線上的頁面用戶最直接的感覺，就是頁面響應時間，也就是頁面打開耗時。

不少前端性能工具對頁面響應時間這個指數只是簡單的在本地模擬下，也就是所謂的「撥測」；或者只是簡單的經過 window.performance 接口把各個數據上傳給使用者，根本沒法展示用戶的真實體驗。

從技術的角度講，一個頁面的打開時間也是要劃分爲各個部分的，例如：首屏打開時間、白屏時間、dom文檔打開時間、資源加載完成時間等；也要重視資源加載耗時詳情，是哪些腳本或者 css 拖慢了頁面的加載這些都要一目瞭然。只有這樣，一旦頁面響應時間過長，相關人員纔能有針對性的去進行維護。

可行工具：New Relic、OneAPM Browser Insight、AppDynamics、Ruxit

3.頁面響應時間分佈

想了想仍是以爲有必要把這個指標從「頁面響應時間」裏面拿出來單獨說。

顧名思義，頁面響應時分佈間就是一段時間內，用戶訪問頁面的響應時間的分佈圖。其實大部分狀況下，一個網站的維護只需照顧到絕大多數用戶就能夠了，沒有必要爲了知足各類極端狀況而耗費各類資源，中國網絡環境的複雜性相信你們都深有體會，因此這種統計就顯得尤其必要，

可行工具：OneAPM Browser Insight、AppDynamics、Ruxit

4.DNS、TCP耗時

瀏覽器和 WEB 服務器鏈接 TCP/IP 的消耗時間以及域名解析時間也是網站優化須要關注指標。

仍是那句話————國內的網絡環境極其複雜，因此致使常常有 DNS，CDN 不給力的狀況，TCP 的鏈接也常常會不穩定。以前國內外有些工具能夠經過模擬撥測的方式來計算 DNS 耗時等數據，但講實在的，只是這種仿真數據的話 DNS 廠家纔不會理你，因此，從用戶真實體驗的角度來收集這類耗時則顯得尤其必要，而如今能作好這一點的工具確實很少，給你們推薦幾個。 可行工具：OneAPM Browser Insight、AppDynamics、Ruxit

#####三.性能測試方法

網站上線前以及上線後，相關的性能測試也是必需要有的。性能測試是一個總稱，具體可細分爲性能測試、負載測試、壓力測試、穩定性測試。

性能測試

以系統設計初期規劃的性能指標爲目標，對系統不斷施加壓力，驗證系統在資源可接受範圍內，是否能達到性能預期。

負載測試

對系統不斷地增長併發請求以增長系統壓力，直到系統的某項或多項性能指標達到安全臨界值，如某種資源已經呈飽和狀態，這時繼續對系統施加壓力，系統的處理能力不但不能提升，反而會降低。

壓力測試

超過安全負載的狀況下，對系統繼續施加壓力，直到系統崩潰或不能再處理任何請求，以此得到系統最大壓力承受能力。

穩定性測試

被測試系統在特定硬件、軟件、網絡環境條件下，給系統加載必定業務壓力，使系統運行一段較長時間，以此檢測系統是否穩定。在不一樣生產環境、不一樣時間點的請求壓力是不均勻的，呈波浪特性，所以爲了更好地模擬生產環境，穩定性測試也應不均勻地對系統施加壓力。

性能測試是一個不斷對系統增長訪問壓力，以得到系統性能指標、最大負載能力、最大壓力承受能力的過程。所謂的增長訪問壓力，在系統測試環境中，就是不斷增長測試程序的併發請求數，通常說來，性能測試遵循以下圖所示的拋物線規律。

性能測試反應的是系統在實際生產環境中使用時，隨着用戶併發訪問數量的增長，系統的處理能力。與性能曲線相對應的是用戶訪問的等待時間（系統響應時間）

在平常運行區間，能夠得到最好的用戶響應時間，隨着併發用戶數的增長，響應延遲愈來愈大，直到系統崩潰，用戶失去響應。

而從 OneAPM 提供的 Browser Insight 的定位分析功能來看，跟這個圖仍是很類似的，只不過是 X 座標軸是響應時間，Y 是訪問次數。

性能測試報告

測試結果報告應可以反映上述性能測試曲線的規律，閱讀者能夠獲得系統性能是否知足設計目標和業務要求、系統最大負載能力、系統最大壓力承受能力等重要信息，下表是一個簡單示例：

當這些數據獲得量化的以後，咱們的目標就很明確了，那麼最終咱們爲了打造一個高性能的網站，須要作哪些工做呢？接下來咱們分析性能優化的一些策略！

#####四.性能優化策略

若是性能測試結果不能知足設計或業務需求，那麼就須要尋找系統瓶頸，分而治之，逐步優化。

1．性能分析

大型網站結構複雜，用戶從瀏覽器發出請求直到數據庫完成操做事務，中間須要通過不少環節，若是測試或者用戶報告網站響應緩慢，存在性能問題，必須對請求經歷的各個環節進行分析，排查可能出現性能瓶頸的地方，定位問題!

排查一個網站的性能瓶頸和排查一個程序的性能瓶頸的手法基本相同：檢查請求處理的各個環節的日誌，分析哪一個環節響應時間不合理、超過預期；而後檢查監控數據，分析影響性能的主要因素是內存、磁盤、網絡、仍是 CPU？是代碼問題仍是架構設計不合理？或者系統資源確實不足？

2．性能優化

定位產生性能問題的具體緣由後，就須要進行性能優化，根據網站分層架構，可分爲 Web 前端性能優化、應用服務器性能優化、存儲服務器性能優化 3 大類，每一類都很是重要，一款好的工具的重要性就不言而喻了。

目前，OneAPM 針對前端性能的優化產品，Browser Insight 可讓用戶免費試用；同時包括針對應用服務器性能優化 Application Insight 產品以及針對存儲服務器性能優化 Cloud Insight產品也都提供了免費版產品，但願可以幫助用戶不斷優化，作出真正意義上的高性能高流量網站！！！