大型網站技術架構，4網站的高性能架構之網站性能測試

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

4.1 網站性能測試

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

4.1.1 不一樣視角下的網站性能

一、用戶視角的網站性能

用戶感覺到的時間，包括用戶計算機和網站服務器通訊的時間、網站服務器處理的時間、用戶計算機瀏覽器構造請求解析響應數據的時間

 

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

 

二、開發人員視角的網站性能

開發人員關注的主要是應用程序自己及其相關子系統的性能，包括響應延遲、系統吞吐量、併發處理能力、系統穩定性等技術指標。

主要優化手段有使用緩存加速數據讀取，使用集羣提升吞吐能力，使用異步消息加快請求響應及實現削峯，使用代碼優化收到改善程序性能。

 

三、運維人員視角的網站性能

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

 

4.1.2 性能測試指標

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

 

一、響應時間

指應用執行一個操做須要的時間，包括從發出請求開始到收到最後響應數據所須要的時間。

重複請求方法：一個請求操做重複執行一萬次，測試一萬次執行須要的總響應時間之和，而後除以一萬，獲得單次請求的響應時間。

 

二、併發數

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

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

 

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

 

爲了真實模擬用戶行爲，測試程序並非啓動多線程而後不停地發送請求，而是在兩次請求之間加入一個隨機等待時間，這個時間被稱做思考時間。

 

三、吞吐量 

指單位時間內系統處理的請求數量，體現系統的總體處理能力。

請求數/秒

頁面數/秒

訪問人數/天

處理的業務數/小時

 

TPS(每秒事務數)

HPS(每秒HTTP請求數)

QPS(每秒查詢數)

 

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

 

這個過程當中，響應時間則是先保持小幅上升，達到吞吐量極限後，快速上升，到達系統崩潰點後，系統失去響應。

 

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

 

四、性能計數器

它是描述服務器或操做系統性能的一些數據指標。

包括System Load、對象與線程數、內存使用、CPU使用、磁盤與網絡I/O等指標。

這些指標也是系統監控的重要參數，對這些指標設置報警閾值，當監控系統發現性能計數器超過閾值時，就向運維和開發人員報警，及時發現處理系統異常。

 

System Load即系統負載，指當前正在被CPU執行和等待被CPU執行的進程數目總和，是反映系統忙閒程度的重要指標。

 

Load的理想值是CPU數目，

高於CPU數目，表示進程在排隊等待CPU調度，表示系統資源不足，影響程序執行性能

低於CPU數目，表示CPU空閒，資源存在浪費

 

Linux系統中使用top命令查看，該值是三個浮點數，表示最近1分鐘，10分鐘，15分鐘的運行隊列平均進程數。

 

 

4.1.3 性能測試方法

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

 

性能測試

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

 

負載測試

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

 

壓力測試

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

 

穩定性測試

被測試系統在特定硬件、軟件、網絡環境下，給系統加載必定業務壓力，使系統運行一段較長時間，以此檢測系統是否穩定。

應不均勻地對系統施加壓力。

 

 性能測試曲線

a~b爲網站的平常運行區間

c爲最大負載點，超出這個點，系統處理能力降低，資源消耗更多

d爲崩潰點，達到極限後，系統不能再處理任何請求。

 

性能測試測試目標：評估系統性能是否符合需求及設計目標

負載測試測試目標：評估當系統由於突發事件超出平常訪問壓力的狀況下，保證系統正常運行狀況下可以承受的最大訪問負載壓力

壓力測試目標：評估可能致使系統崩潰的最大訪問負載壓力。

 

 

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

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

 

4.1.4 性能測試報告

 

4.1.5 性能優化策略

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

 

一、性能分析

排查一個網站的性能瓶頸的手法：

檢查請求處理的各個環節的日誌，分析哪一個環節響應時間不合理、超過預期；

而後檢查監控數據，分析影響性能的主要因素使內存、磁盤、網絡、仍是CPU，是代碼問題仍是架構設計不合理，或者系統資源確實不足。

 

二、性能優化

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

 

小結：

這一篇學習了，性能測試指標，性能測試方法，根據性能測試結果判斷是否要優化，簡單的介紹了性能優化策略，包括性能分析的思路，以及簡單的講了下性能優化，後面文章逐個學習分層架構中三大類優化措施。