什麼叫高效能的網站？ 

兩個網站效能架構設計方案：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架構設計。目前就職英特爾亞太研發中心從事雲端計算與大資料方面的研發工作。本文節選自《大型網站技術架構：核心原理與案例分析》一書，李智慧著，由電子工業出版社出版。