1.1. 性能測試的基礎概念

性能可以理解為一個系統實現其功能的能力，從宏觀上可以描述為系統能夠穩定運行，高並發訪問時系統不會出現宕機，系統處理完成用戶請求需要的時間，系統能夠同時支撐的並發訪問量，系統每秒可以處理完成的事物數等，從微觀上可以描述為處理每個事務的資源開銷，資源的開銷可以包括CPU，磁盤IO，內存，網絡傳輸帶寬等，甚至可以體現為服務器鏈接數，線程數，JVM Heap等的使用情況，也可以表現為內存的分配回收是否及時，緩存規則的命中率等。

性能到底有多重要呢，我們可以舉一個網站訪問的例子來說明，一個網頁的加載速度如果超過4-5秒，可能25%的人會選擇放棄。百度的搜索結果響應時間慢0.4秒，一天的搜索量可能會減少千萬左右。所以一個系統，一個網站的性能決定了其能夠支撐業務的能力。

不同的群體對性能的理解可能會存在很大的差異，普通的用戶更加關心響應時間和穩定性。

l 訪問頁面響應還要讓我等多久才能加載出來？

l 為什麽有時候會訪問失敗？為什麽會出現502？

架構師和工程師可能更加關心架構設計和代碼編寫的性能

l 應用架構設計是否合理？

l 技術架構設計是否合理？

l 數據架構設計是否合理？

l 部署架構設計是否合理？

l 代碼是否存在性能問題？

l JVM中是否有不合理的內存分配和使用？

l 線程同步和線程鎖是否合理？

l 代碼的計算算法是否可以進一步優化以減少CPU的消耗時間？

運維工程師可能更加關心系統的監控以及穩定性情況

l 服務器各項資源使用率在正常範圍內嗎？

l 數據庫的鏈接數在正常範圍內嗎？

l Sql執行時間正常嗎，是否存在慢查詢日誌？

l 系統能夠支撐7*24小時連續不間斷的業務訪問嗎？

l 系統是高可用的嗎，服務器節點宕機了會影響用戶使用嗎？

l 對節點擴容後，可以提高系統的性能嗎？

l

1.1.1 性能測試的分類

性能測試的類型通常包括如下幾種：

l 性能測試：尋求系統在正常負載下的各項性能指標， 或者通過調整並發用戶數，使系統資源的利用率處於正常水平時獲取到系統的各項性能指標。

l 負載測試：系統在不同負載下的性能表現，通過該項測試可以尋求到系統在不同負載下的性能變化曲線，從而尋求到性能的拐點。例如負載測試時，在只不斷遞增並發用戶數時，觀察各項性能指標的變化規律，找到系統能到達的最大TPS，並且觀察此時系統處理的平均響應時間和各項系統資源和硬件資源的消耗情況。

l 壓力測試：系統在高負載下的性能表現，該項測試主要為了尋求系統能夠承受的最大負載以及此時系統的吞吐率，通過該測試也可以發現系統在超高負載下是否會出現崩潰無法訪問以及在系統負載減小後，系統性能能否自動恢復。

l 基準測試：針對待測系統進行版本執行的測試，采集各項性能指標作為後期版本性能的對比。

l 穩定性測試：以正常負載或者略高於正常負載來對系統進行長時間的測試，檢測系統是否可以長久穩定運行以及系統的各項性能指標會不會隨著時間發生明顯變化。

l 擴展性測試：通常用於新上線的系統或者新搭建的系統環境，通過先測試單臺服務器的處理能力，然後慢慢增加服務器的數量，測試集群環境下單臺服務器的處理能力是否有損耗，集群環境的性能處理能力是否可以呈現穩定增加。

1.1.2 性能測試的場景

性能測試的場景類型通常包含如下幾種：

l 業務場景：通常指的是系統的業務處理流程，描述具體的用戶行為，通過對用戶行為進行分析劃分出不同的業務場景，是性能測試時測試場景設計的重要來源。

l 測試場景：測試場景是對業務場景的真實模擬，測試場景的設計應該盡可能貼近真實的業務場景，有時候由於測試條件的限制，可以適當做一些調整和特殊的設置等。

l 單場景：指的是只涉及單個業務流程的測試場景，目的是測試系統的單個業務處理能力是否達到預期，並且得到系統資源利用正常情況下的最大TPS，平均響應時間等性能指標。

l 混合場景：測試場景中涉及到多個業務流程，並且每個業務流程在混合的業務流程中占的比重會不同，該比重一般根據實際的業務流程來設定，盡可能符合實際的業務需要，該測試場景的目的是為了測試系統的混合業務處理能力是否滿足預期要求。並且評估到系統的混合業務處理容量最大能達到多少。

1.2. 常見的性能測試指標

衡量一個系統性能的好壞，在性能測試中會使用一些性能指標來進行分析和描述，以下是一些最常用的性能指標。

1.2.1 響應時間

請求或者某個操作從發出的時間到收到服務器響應的時間的差值，在性能測試中，一般統計的是事物的響應時間。

下圖是一次標準http請求可能經過的處理路徑和節點，那麽響應的時間的計算方式就是所有路徑消耗的時間和每個服務器節點處理時間的累加，通常是網絡時間+應用程序的處理時間。

1.2.1 TPS/QPS

事務：自定義的某個操作或者一組操作的集合，例如在一個系統的登錄頁面，輸入用戶名和密碼，從點擊登錄按鈕開始到登錄完成跳轉到頁面並且新的頁面完全加載完成，這一個操作我們就可以定義為一個事務。

TPS是Transaction Per Second的縮寫，即系統每秒能夠處理的交易和事物的數量，一般統計的是每秒通過的事物數。

QPS是每秒查詢率(Query Per Second) 的縮寫，是對一個特定的查詢服務器在規定時間內所處理流量多少的衡量標準。

1.2.2 並發用戶

在真實的用戶操作中，用戶的每個相鄰操作之間都會有一定的間隔時間（在性能測試中，我們稱為用戶思考時間），所以並發用戶一般有絕對並發和相對並發之分，絕對並發是指某個時間點同時一起向服務器發出請求的並發用戶數，相對並發是指一段時間內向服務器發出請求的並發用戶總數。單就性能指標而言，系統的並發用戶數是指系統可以同時承載的正常使用系統功能的用戶的總數量。

針對並發用戶我們舉例說明，在京東購物網站上購買一件商品的流程包括登錄，瀏覽商品，把商品加入購物車，去購物車結算，確認商品清單，確認收貨地址信息，最後提交訂單去支付。如果200人同時按照這個流程在購買一件商品，但因為每個人購買商品的步驟有快有慢，所以在同一時間點向服務器發出請求的用戶是肯定不會有200個的，會遠遠小於200個，我們假設為20，那麽上面說的200個用戶就是相對並發用戶數，而20就是絕對的並發用戶數。

1.2.3 PV/UV

l PV：Page View的簡寫，即頁面的瀏覽量或者點擊量，用戶每次對系統或者網站中任何頁面的訪問均會被記錄一次，用戶如果對同一頁面進行多方訪問，那麽訪問量會進行累加。PV一般是衡量電子商務網站性能容量的重要指標，PV的統計可以分為全天PV，每個小時的PV以及峰值PV（高峰1小時的PV）。

l UV：Unique Visitor的簡寫，即指系統的獨立訪客，訪問系統網站的一臺電腦客戶端會稱為一個訪客，每天00:00點到次日00:00點內相同的客戶端只能被計算一次，同樣UV的統計也可以分為全天UV，每個小時的UV以及峰值UV（高峰1小時的UV）。

PV和UV通常是衡量Web網站的兩個非常重要的指標，PV/s一般是由TPS通過一定的模型轉化為PV，比如如果把每一個完整的頁面都定義為一個事務，那麽TPS就可以等同於PV/s。PV和UV之間一般存在一個比例，PV/UV可以理解為每個用戶平均瀏覽訪問的頁面數，這個比值在不同的時間點會所波動，比如雙11電商大促時PV/UV的比重會比平時高很多。

1.2.4 點擊率

每秒的Hit點擊數我們稱之為點擊率，該性能指標反映了客戶端每秒向服務端提交的請求數，通常一個hit對應了一次http請求，在性能測試中，我們一般不發起靜態請求（指的是對靜態資源的請求，比如js，css圖片文件等），所以hit通常是指的動態請求。在性能測試中，我們之所以不發起靜態請求是因為靜態請求一般是可以走緩存，比如CDN等，很多靜態請求一般都不需要經過應用服務器的處理，要麽直接走CDN緩存，要麽直接請求到Web服務器就被處理完成了。

1.2.5 吞吐量

吞吐量是指系統在單位時間內處理客戶端請求的數量，不同的角度，吞吐量的計算方式可以不一樣。

l 從業務角度：吞吐量可以用請求數/s，頁面數/s等來進行衡量計算。

l 從網絡角度：吞吐量可以用字節/s來進行衡量計算。

l 從應用角度：吞吐量指標反映的是服務器承受的壓力即系統的負載能力

一個系統的吞吐量一般與一個請求處理對CPU的消耗、帶寬的消耗、IO和內存資源的消耗情況等緊密相連。

1.2.6 資源開銷

每個請求或者事務對系統資源的消耗，用來衡量請求或者事務對資源的消耗程度，例如對CPU的消耗可以用占用CPU的秒數或者核數來衡量，對內存的消耗可以用內存使用率來衡量，對IO的消耗可以用每秒讀寫磁盤的字節數來衡量。在性能測試中，資源的開銷是一個可以量化的概念，資源的開銷情況對性能指標有著重要的影響，我們一般做性能優化時，都是盡可能讓每一個請求或者事務對系統資源的消耗減少到最小。

1.3. 性能測試的基本流程

通常情況下，性能測試一般會經歷如下階段，這些階段可以和很多性能測試工具對應起來，比如分析性能測試結果可以用Loadrunner的ANALYSIS工具來實現。

1.3.1 性能需求分析

l 熟悉被壓測系統的基本業務流程，明確此次性能測試要達到的目標，與產品經理、業務人員、架構師、技術經理一起溝通，找到業務需求的性能點。

l 熟悉系統的應用架構、技術架構、數據架構、部署架構等，找到與其他系統的交互流程，明確系統部署的硬件配置信息，軟件配置信息，把對性能測試有重要影響的關鍵點需要明確的列舉出來，一般包括如下：

² 用戶發起請求的順序、請求之間的相互調用關系。

² 業務數據流走向、數據是如何流轉的、經過了哪些應用服務、經過了哪些存儲服務

² 評估被壓測系統可能存在的重點資源消耗，是IO消耗型、CPU消耗型還是內存消耗型，這樣在壓測執行時可以重點進行監控。

² 關註應用的部署架構，如果是集群部署，壓測時需要關註應用的負載均衡轉發是否均勻，每臺應用服務器資源消耗是否大體一致。

² 和技術經理一起溝通，明確應用的並發架構，是采用多線程處理還是多進程處理，重點需要關註是否會死鎖、數據不一致，線程同步鎖是否合理（鎖的粒度一般不宜過大，過大時可能會影響並發線程的處理）等。

l 明確系統上線後可能會達到的最大並發用戶數，用戶期望的平均響應時間以及峰值時的業務吞吐量，將這些信息轉化為性能需求指標。

1.3.2 制定性能測試計劃

性能測試計劃是性能測試的指導，是一系列測試活動的依據，在制定性能測試計劃時需要明確系統的上線時間點、當前項目的進度以及所處的階段、可以供調配的硬件資源和性能測試人員。一個完整的性能測試計劃一般包括如下幾個部分：

l 性能測試計劃編寫的目的：主要是作為整個性能測試過程的指導，讓性能測試環境搭建、測試策略的選取、任務與進度事項跟蹤、性能測試風險分析等事項有序的進行，同時也需要明確此次性能測試預期需要達到的標準以及性能測試完成退出測試的條件。

l 明確各個階段的具體執行時間點以及對應的責任人：

• 預計由誰何時開始性能需求分析，何時結束性能需求分析
• 預計由誰何時完成性能測試方案的編寫，何時結束性能測試方案的編寫
• 預計由誰何時完成性能測試案例的編寫，何時結束性能測試案例的編寫
• 預計由誰何時開始搭建性能測試環境，何時結束性能測試環境的搭建
• 預計由誰何時開始準備性能測試需要的數據，何時準備完畢
• 預計由誰何時開始編寫性能測試腳本，何時編寫完畢，性能測試腳本的編寫一般包含如下步驟：

² 按照性能測試場景，開始錄制性能測試腳本或者直接編寫性能測試腳本，此時可能用到的常見性能測試工具包括Loadrunner、BadBoy、Jmeter、nGrinder等。

² 根據準備好的測試數據，對性能測試腳本進行參數化，添加集合點，事務分析點等。

² 對性能腳本進行試運行調試，確保不出現報錯，並且可以覆蓋到測試場景中所有操作。

• 預計由誰何時開始性能測試的執行，何時完成性能測試的執行，此階段一般需要完成如下事項：

² 完成每一個性能測試場景和案例的執行，記錄相關的性能測試結果，明確性能曲線的變化趨勢，獲取性能的拐點等。

² 根據性能測試的結果，評估性能數據是否可以滿足預期，從性能測試結果數據中分析存在的性能問題。

² 針對性能問題，進行性能定位和優化，然後進行二次壓測，直至性能數據可以滿足預期，性能測試問題得到解決。

² 完成性能測試分析報告的編寫。

• 性能測試風險的分析和控制：評估可能存在的風險和不可控的因素以及這些風險和因素對性能測試可能產生的影響，針對這些風險因素需要給出對應的短期和長期的解決方案。性能測試風險一般包括如下：

² 性能測試環境因素：無法預期完成性能測試環境的搭建，這中間的原因可能是硬件引起也可能是軟件引起，硬件原因一般可能包括性能壓測服務器無法按時到位、服務器硬件配置無法滿足預期（一般要求性能壓測服務器硬件配置等同於生產環境，服務器的節點數可以少於生產環境，但是需要保證每個應用服務至少部署了兩臺節點服務器）。軟件原因可能包括性能測試環境軟件配置無法和生產環境保持一致（一般要求性能壓測環境軟件配置，比如軟件版本、數據庫版本、驅動版本等要和生產環境完全保持一致）。

² 性能測試人員因素：性能測試人員無法按時到位參與項目的性能測試，如果出現這樣的風險，肯定會導致性能測試無法預期進行，需要立即向項目經理進行匯報，以確保可以協調到合適的人員，因為這是一個非常嚴重的風險。

² 性能測試結果無法達到預期：即系統的性能無法達到生產預期上線要求或者存在性能問題無法解決，性能調優其實本身就是一個長期不斷優化的過程，此時可以看是否通過服務器的橫向或者縱向擴容來解決，如果還是無法解決，那麽也需要提前上報風險。

1.3.3 編寫性能測試方案

在有了性能測試計劃後，我們就需要按照性能需求分析的結果來制定性能測試方案，即按照什麽樣的思路和策略去測試、需要設計哪些測試場景以及測試場景執行的先後順序、每個測試場景需要重點關註的性能點等，一般包括如下：

• 測試場景的設計

² 單場景設計

² 混合場景設計

• 定義事務：測試方案中需要明確定義好壓測事務，方便分析響應時間（特別是在混合場景中，事務的定義可以方便分析每一個場景響應時間的消耗）。比如我們對淘寶網購買商品這一場景進行壓測，可以把下訂單定義為一個事務，把支付也定義為一個事務，在壓測結果中，如果響應時間較長時，就可以對每一個事務進行分析，看哪個事務耗時最長。
• 明確監控對象：針對每個場景，明確可能的性能瓶頸點（比如數據庫查詢、Web服務器服務轉發、應用服務器等）、需要監控的對象，比如TPS、平均響應時間、點擊率、並發連接數、CPU、內存、IO等。
• 定義測試策略：

² 明確性能測試的類型：需要進行哪些類型的性能測試，比如負載測試、壓力測試、穩定性測試等。

² 明確性能測試場景的執行順序，一般是先執行單場景，後執行混合場景測試。

² 如果是進行壓力測試，還需要明確加壓的方式，比如按照開始前5分鐘，20個用戶，然後每隔5分鐘，增加20個用戶來進行加壓。

• 性能測試工具的選取：

² 性能測試工具有很多，常見的性能測試工具有Loadrunner、Jmeter、nGrinder等，那麽如何來選取合適的性能測試工具呢

l 一般性能測試工具都是基於網絡協議開發的，所以我們需要明確待壓測系統使用的協議，盡可能和被壓測系統的協議保持一致或者至少要支持被壓測系統的協議。

l 理解每種工具實現的原理，比如哪些工具適用於同步請求的壓測，哪些工具適用於異步請求的壓測。

l 壓測時明確連接的類型，比如屬於長連接還是短連接、一般連接多久能釋放

l 明確性能測試工具並發加壓的方式，比如是多線程加壓還是多進程加壓，一般采用的都是多線程加壓。

• 明確硬件配置和軟件配置：

² 硬件配置一般包括：服務器的CPU配置、內存配置、硬盤存儲配置、集群環境下還要包括集群節點的數量配置等。

² 軟件配置一般包括：

l 操作系統配置

l 應用版本配置：應用版本要和線上保持一致，特別是中間件、數據庫組件等的版本，因為不同版本，其性能可能不一樣。

l 參數配置：比如web中間件服務器的負載均衡、反向代理參數配置、數據庫服務器參數配置等。

² 網絡配置：一般為了排除網絡瓶頸，除非有特殊要求外，通常建議在局域網下進行性能測試，並且明確壓測服務器的網卡類型以及網絡交換機的類型，比如屬於千兆網卡或者交換機屬於百兆交換機還是千兆交換機等，這對我們以後分析性能瓶頸會有很大的幫助，在網絡吞吐量較大的待壓測系統中，網絡有時候也很容易成為一個性能瓶頸。

1.3.4 編寫性能測試案例

性能測試案例一般是對性能測試方案中性能壓測場景的進一步細化，一般包括如下：

l 預置條件：一般指執行此案例需要滿足何種條件，性能測試案例才可以執行。比如性能測試數據需要準備到位、性能測試環境需要啟動成功等。

l 執行步驟：詳細描述案例執行的步驟，一般需要描述包括測試腳本的錄制和編寫、腳本的調試、腳本的執行過程（比如如何加壓、每個加壓的過程持續多久等）、需要觀察和記錄的性能指標、需要明確性能曲線的走勢、需要監控哪些性能指標等。

l 性能預期結果：描述性能測試預期需要達到的結果，比如TPS需要達到多少、平均響應時間需要控制到多少以內、服務器資源的消耗需要控制在多少以內等。

性能測試和性能分析的基礎概念