瞬時響應：網站的高性能架構

原文地址：http://www.admin10000.com/document/3047.html

什麼叫高性能的網站？

　　兩個網站性能架構設計方案：A方案和B方案，A方案在小於100個併發用戶訪問時，每一個請求的響應時間是1秒，當併發請求達到200的時候，請求的響應時間將驟增到10秒。B方案不論是100個併發用戶訪問仍是200個併發用戶訪問，每一個請求的響應時間都差很少是1.5秒。哪一個方案的性能好？若是老闆說「咱們要改善網站的性能」，他指的是什麼？

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

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

　　網站性能測試

　　性能測試是性能優化的前提和基礎，也是性能優化結果的檢查和度量標準。不一樣視角下的網站性能有不一樣的標準，也有不一樣的優化手段。

　　不一樣視角下的網站性能

　　軟件工程師說到網站性能的時候，一般和用戶說的不同。

　　1．用戶視角的網站性能

　　從用戶角度，網站性能就是用戶在瀏覽器上直觀感覺到的網站響應速度快仍是慢。用戶感覺到的時間，包括用戶計算機和網站服務器通訊的時間、網站服務器處理的時間、用戶計算機瀏覽器構造請求解析響應數據的時間，如圖1所示。

　　圖1 用戶視角的網站性能

　　不一樣計算機的性能差別，不一樣瀏覽器解析HTML速度的差別，不一樣網絡運營商提供的互聯網寬帶服務的差別，這些差別最終致使用戶感覺到的響應延遲可能會遠遠大於網站服務器處理請求須要的時間。

　　在實踐中，使用一些前端架構優化手段，經過優化頁面HTML式樣、利用瀏覽器端的併發和異步特性、調整瀏覽器緩存策略、使用CDN服務、反向代理等手段，使瀏覽器儘快地顯示用戶感興趣的內容、儘量近地獲取頁面內容，即便不優化應用程序和架構，也能夠很大程度地改善用戶視角下的網站性能。

　　2．開發人員視角的網站性能

　　開發人員關注的主要是應用程序自己及其相關子系統的性能，包括響應延遲、系統吞吐量、併發處理能力、系統穩定性等技術指標。主要的優化手段有使用緩存加速數據讀取，使用集羣提升吞吐能力，使用異步消息加快請求響應及實現削峯，使用代碼優化手段改善程序性能。

　　3．運維人員視角的網站性能

　　運維人員更關注基礎設施性能和資源利用率，如網絡運營商的帶寬能力、服務器硬件的配置、數據中心網絡架構、服務器和網絡帶寬的資源利用率等。主要優化手段有建設優化骨幹網、使用高性價比定製服務器、利用虛擬化技術優化資源利用等。

　　性能測試指標

　　不一樣視角下有不一樣的性能標準，不一樣的標準有不一樣的性能測試指標，從開發和測試人員的視角，網站性能測試的主要指標有響應時間、併發數、吞吐量、性能計數器等。

　　1．響應時間

　　指應用執行一個操做須要的時間，包括從發出請求開始到收到最後響應數據所須要的時間。響應時間是系統最重要的性能指標，直觀地反映了系統的「快慢」。表4.1列出了一些經常使用的系統操做須要的響應時間。

　　表1 經常使用系統操做響應時間表

　　測試程序經過模擬應用程序，記錄收到響應和發出請求之間的時間差來計算系統響應時間。可是記錄及獲取系統時間這個操做也須要花費必定的時間，若是測試目標操做自己須要花費的時間極少，好比幾微秒，那麼測試程序就沒法測試獲得系統的響應時間。實踐中一般採用的辦法是重複請求，好比一個請求操做重複執行一萬次，測試一萬次執行須要的總響應時間之和，而後除以一萬，獲得單次請求的響應時間。

　　2．併發數

　　指系統可以同時處理請求的數目，這個數字也反映了系統的負載特性。對於網站而言，併發數即網站併發用戶數，指同時提交請求的用戶數目。

　　與網站併發用戶數相對應的還有網站在線用戶數（當前登陸網站的用戶總數）和網站系統用戶數（可能訪問系統的總用戶數，對多數網站而言就是註冊用戶數）。其數量比較關係爲：

　　網站系統用戶數>>網站在線用戶數>>網站併發用戶數

　　在網站產品設計初期，產品經理和運營人員就須要規劃不一樣發展階段的網站系統用戶數，並以此爲基礎，根據產品特性和運營手段，推算在線用戶數和併發用戶數。這些指標將成爲系統非功能設計的重要依據。

　　現實中，常常看到某些網站，特別是電商類網站，市場推廣人員興致勃勃地打廣告打折促銷，用戶興致勃勃地去搶購，結果活動剛一開始，就由於併發用戶數超過網站最大負載而響應緩慢，急性子的用戶不停刷新瀏覽器，致使系統併發數更高，最後以服務器系統崩潰，用戶瀏覽器顯示「Service is too busy」而了結。出現這種狀況，有多是網站技術準備不充分致使，也有多是運營人員錯誤地評估併發用戶數致使。

　　測試程序經過多線程模擬併發用戶的辦法來測試系統的併發處理能力，爲了真實模擬用戶行爲，測試程序並非啓動多線程而後不停地發送請求，而是在兩次請求之間加入一個隨機等待時間，這個時間被稱做思考時間。

　　3．吞吐量

　　指單位時間內系統處理的請求數量，體現系統的總體處理能力。對於網站，能夠用「請求數/秒」或是「頁面數/秒」來衡量，也能夠用「訪問人數/天」或是「處理的業務數/小時」等來衡量。TPS（每秒事務數）是吞吐量的一個經常使用量化指標，此外還有HPS（每秒HTTP請求數）、QPS（每秒查詢數）等。

　　在系統併發數由小逐漸增大的過程當中（這個過程也伴隨着服務器系統資源消耗逐漸增大），系統吞吐量先是逐漸增長，達到一個極限後，隨着併發數的增長反而降低，達到系統崩潰點後，系統資源耗盡，吞吐量爲零。

　　而這個過程當中，響應時間則是先保持小幅上升，到達吞吐量極限後，快速上升，到達系統崩潰點後，系統失去響應。系統吞吐量、系統併發數及響應時間之間的關係將在本章後面內容中介紹。

　　系統吞吐量和系統併發數，以及響應時間的關係能夠形象地理解爲高速公路的通行情況：吞吐量是天天經過收費站的車輛數目（能夠換算成收費站收取的高速費），併發數是高速公路上的正在行駛的車輛數目，響應時間是車速。車輛不多時，車速很快，可是收到的高速費也相應較少；隨着高速公路上車輛數目的增多，車速略受影響，可是收到的高速費增長很快；隨着車輛的繼續增長，車速變得愈來愈慢，高速公路愈來愈堵，收費不增反降；若是車流量繼續增長，超過某個極限後，任何偶然因素都會致使高速所有癱瘓，車走不動，費固然也收不着，而高速公路成了停車場（資源耗盡）。

　　網站性能優化的目的，除了改善用戶體驗的響應時間，還要儘可能提升系統吞吐量，最大限度利用服務器資源。

　　4．性能計數器

　　它是描述服務器或操做系統性能的一些數據指標。包括System Load、對象與線程數、內存使用、CPU使用、磁盤與網絡I/O等指標。這些指標也是系統監控的重要參數，對這些指標設置報警閾值，當監控系統發現性能計數器超過閾值時，就向運維和開發人員報警，及時發現處理系統異常。

　　System Load即系統負載，指當前正在被CPU執行和等待被CPU執行的進程數目總和，是反映系統忙閒程度的重要指標。多核CPU的狀況下，完美狀況是全部CPU都在使用，沒有進程在等待處理，因此Load的理想值是CPU的數目。當Load值低於CPU數目的時候，表示CPU有空閒，資源存在浪費；當Load值高於CPU數目的時候，表示進程在排隊等待CPU調度，表示系統資源不足，影響應用程序的執行性能。在Linux系統中使用top命令查看，該值是三個浮點數，表示最近1分鐘，10分鐘，15分鐘的運行隊列平均進程數。如圖4.2所示。

圖2 在Linux命令行查看系統負載

　　性能測試方法

　　性能測試是一個總稱，具體可細分爲性能測試、負載測試、壓力測試、穩定性測試。

• 性能測試

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

• 負載測試

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

• 壓力測試

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

• 穩定性測試

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

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

　　圖4.3中的橫座標表示消耗的系統資源，縱座標表示系統處理能力（吞吐量）。在開始階段，隨着併發請求數目的增長，系統使用較少的資源就達到較好的處理能力（a～b段），這一段是網站的平常運行區間，網站的絕大部分訪問負載壓力都集中在這一段區間，被稱做性能測試，測試目標是評估系統性能是否符合需求及設計目標；隨着壓力的持續增長，系統處理能力增長變緩，直到達到一個最大值（c點），這是系統的最大負載點，這一段被稱做負載測試。測試目標是評估當系統由於突發事件超出平常訪問壓力的狀況下，保證系統正常運行狀況下可以承受的最大訪問負載壓力；超過這個點後，再增長壓力，系統的處理能力反而降低，而資源消耗卻更多，直到資源消耗達到極限（d點），這個點能夠看做是系統的崩潰點，超過這個點繼續加大併發請求數目，系統不能再處理任何請求，這一段被稱做壓力測試，測試目標是評估可能致使系統崩潰的最大訪問負載壓力。

圖3 性能測試曲線

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

圖4 併發用戶訪問響應時間曲線

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

　　性能測試報告

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

表2 性能測試結果報告

　　性能優化策略

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

　　1．性能分析

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

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

　　2．性能優化

　　定位產生性能問題的具體緣由後，就須要進行性能優化，根據網站分層架構，可分爲Web前端性能優化、應用服務器性能優化、存儲服務器性能優化3大類。

　　李智慧，曾在阿里巴巴擔任技術專家，參與阿里巴巴基礎技術平臺開發和www.alibaba.com架構設計。目前就任英特爾亞太研發中心從事雲計算與大數據方面的研發工做。本文節選自《大型網站技術架構：核心原理與案例分析》一書，李智慧著，由電子工業出版社出版。