「大型網站架構設計」—— 網站性能測試

2019 年 10 月 25 日
筆記

嘿，筆者的個人博客已經孵化完成啦?，歡迎大家來逛逛。以後的文章也會在博客進行首發，快來關注我吧，我們繼續一起探討技術一同進步~

本文主要是筆者對《大型網站技術架構》一書的總結歸納。主要通過兩種方式展現，一是通過「思維導圖」的形式輸出；另一種，就是本文以圖文的形式更加詳細和展開的描述『大型網站技術架構』的方方面面。

三，網站性能測試

性能測試是性能優化的前提和基礎，也是性能優化結果的檢查和度量標準。

3.1 不同視角下的網站性能

用戶視角的網站性能從用戶角度，網站性能就是用戶在瀏覽器上直觀感受到的網站響應速度快還是慢。

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

開發人員視角的網站性能開發人員關注的主要是應用程序本身及其相關子系統的性能，包括： a）響應延遲 ———— 優化手段：使用緩存加速數據讀取； b）系統吞吐量 ———— 優化手段：使用集群提高吞吐能力； c）並發處理能力 ———— 優化手段：使用異步消息加快請求響應以及實現削峰； d）系統穩定性 ———— 優化手段：使用代碼優化手段改善程序性能等技術指標。主要的優化手段有： a）使用緩存加速數據讀取； b）使用集群提高吞吐能力； c）使用異步消息加快請求響應以及實現削峰； d）使用代碼優化手段改善程序性能
運維人員視角的網站性能運維人員更關注基礎設施性能和資源利用率，如網絡運營商的帶寬能力、服務器硬件的配置、數據中心網絡架構、服務器和網絡帶寬的資源利用率等。主要的優化手段有建設優化骨幹網、使用高性價比定製服務器、利用虛擬化技術優化資源利用等。

3.2 性能測試指標

從開發和測試人員的視角，網站性能測試的主要指標有： a）響應時間； b）並發數； c）吞吐量； d）性能計數器；等。

響應時間響應時間：指應用執行一個操作需要的時間，包括從發出請求開始到收到最後響應數據所需的時間。響應時間是系統最重要的性能指標。如果測試目標操作本身需要花費的時間極少，比如幾微秒，那麼測試程序就無法測試得到系統的響應時間。實踐中通常採用的辦法是重複請求，比如一個請求操作重複執行一萬次，然後求平均單次請求的響應時間。
並發數並發數：指系統能夠同時處理請求的數目，這個數字也反映了系統的負載特性。網站系統用戶 >> 網站在線用戶數 >> 網站並發用戶數根據產品特性和運營手段，推算在線用戶數和並發用戶數。
吞吐量吞吐量：指單位時間內系統處理的請求數量，體現系統的整體處理能力。 TPS（每秒事務數）是吞吐量的一個常量化指標，此外還有 HPS（每秒 HTTP 請求數）、QPS（每秒查詢數）等。 TPS ———— Transactions Per Second（客戶端）它是軟件測試結果的測量單位。一個事務是指一個客戶機向服務器發送請求然後服務器做出反應的過程。客戶機在發送請求時開始計時，收到服務器響應後結束計時，以此來計算使用的時間和完成的事務個數。 QPS ———— Question Per Second（服務端） QPS 是一台服務器每秒能夠響應的查詢次數，是對一個特定的查詢，服務器在規定時間內所處理流量多少的衡量標準。在系統並發數由小逐漸增大的過程中（這個過程也伴隨着服務器系統資源消耗逐漸增大），系統吞吐量是先逐漸增加，達到一個極限後，隨着並發數的增加反而下降，達到系統崩潰點後，系統資源耗盡，吞吐量為零。而這個過程中，響應時間則是先保持小幅上升，到達吞吐量極限後，快速上升，到達系統崩潰點後，系統失去響應。系統吞吐量和系統並發數，以及響應時間的關係可以形象地理解為高速公路的通行狀況：吞吐量是每天通過收費站的車輛數目（可以換算成收費站收取的高速費），並發數是高速公路上的正在行駛的車輛數目，響應時間是車速。車輛很少時，車速很快，但是收到的高速費也相應較少；隨着高速公路上車輛數目的增多，車速略受影響，但是收到的高速費增加很快；隨着車輛的繼續增加，車速變得越來越慢，高速公路越來越堵，收費不增反降；如果車流量繼續增加，超過某個極限後，任何偶然因素都會導致高速全部癱瘓，車走不動，費當然也收不着，而高速公路成了停車場（資源耗盡）。
性能計數器性能計數器：它是描述服務器或操作系統性能的一些數據指標。包括： a）System Load； b）對象與線程數； c）內存使用； d）CPU 使用； e）磁盤與網絡 I/O；等指標。 System Load 即系統負載，指當前正在被 CPU 執行和等待被 CPU 執行的進程數目總和，是反映系統忙閑程度的重要指標。多核 CPU 的情況下，完美情況是所有 CPU 都在使用，沒有進程在等待處理，所以 Load 的理想值是 CPU 的數目。

3.3 性能測試方法

性能測試是一個總體，具體可細分為： ① 性能測試 ② 負載測試 ③ 壓力測試 ④ 穩定性測試在不同生成環境、不同時間的請求壓力是不均勻的，呈波浪特性，因此為了更好地模擬生產環境，穩定性測試也應不均勻地對系統施加壓力。

一般來說，性能測試遵循如圖4.3所示的拋物線規律

性能測試曲線

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

與性能曲線相對應的是用戶訪問的等待時間（系統響應時間）：

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

3.4 性能測試報告

測試結果報告應該能夠反映上述性能測試曲線的規律，閱讀者可以得到系統性能是否滿足設計目標和業務需求、系統最大負載能力、系統最大壓力承受能力等重要信息。

性能測試結果報告：

性能測試結果報告

3.5 性能優化策略

性能分析排除一個網站的性能瓶頸和排查一個程序的性能瓶頸的手法基本相同：檢查請求處理的各個環節的日誌，分析哪個環節響應時間不合理、超過預期；然後檢查監控數據，分析影響性能的主要因素是內存、磁盤、網絡、還是 CPU，是代碼問題還是架構設計不合理，或者系統資源確實不足。
性能優化性能優化，根據網站分層架構，可分為： ① Web 前端性能優化 ② 應用服務器性能優化 ③ 存儲服務器性能優化