什么叫高性能的網站？

兩個網站性能架構設計方案：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大類。