效能測試和效能分析的基礎概念
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需要達到多少、平均響應時間需要控制到多少以內、伺服器資源的消耗需要控制在多少以內等。