閱讀全文需10分鍾，篇幅較長，但內容很具有參考價值，請耐心讀完
1. 前言
本文是公號內性能專題，更新的第四篇，前三篇可參照上述。本想從理論到實踐，以循序漸進的形式為大家分享介紹性能的知識體系，《性能專題之服務端測試》這部分，內容其實已經編寫整理差不多了，完整文章列表如下：
但從前三篇的反饋來看，貌似大部分讀者對理論的部分並不太感興趣。雖然說實踐很重要，但如果缺乏理論基礎，真正實施起來也會變得毫無章法。
考慮到公號內大部分讀者的偏好，本次推文，將作為服務端性能測試理論這部分的最后一篇《性能測試實施全過程指南》。從下一篇開始將結合服務端性能測試的兩款常用工具進行工具實戰操作：Jmeter和Locust。
關於Locust框架連載內容提前預告：
看到框架大綱，就問你期不期待，對於內容期待的讀者，可在下方留言。
2. 開篇：總體策略
通過制定性能測試實施指南，從技術角度對性能測試實施過程中所涉及到的關鍵技術進行規范，能更好地從技術上來規避系統上線后的風險、評估線上系統的真實能力、根據業務模型摸底線上能力以提前應對。
該篇的性能測試實施指南，基本能適用於所有需要性能測試的項目。對性能測試實施過程能起到非常重要作用，整個實施過程主要包括有：
- 系統環境
- 測試指標
- 業務模型
- 數據量
- 測試模型
- 測試類型
- 腳本（API）
- 場景
- 監控
- 瓶頸分析
- 調優
3. 系統環境
3.1 分析
系統環境常分為生產環境、測試環境等。兩個環境的方案各有其優缺點，生產環境衡量的精准度較高，參考效果更好，但是需要清理相關的測試數據（同時要保證數據刪除的完整性，基礎數據的構造參考后續數據量部分）或者BI統計的時候過濾，或者更徹底的方案是參考阿里首創的全鏈路壓測方式，生產環境的壓測盡量挑選在低峰期進行，避免對生產業務造成影響。
單獨的測試環境風險可控，難點在環境的構建上，規模和生產一致的成本也是最高的，所以一般而言有通過等比構建（1/2，1/4，1/8等），甚至是生產環境中部分應用獨立部署測試集群，數據庫共用的方式，此外測試環境需要從生產環境中導入脫敏的基礎數據，比如至少是最近半年或者1年的，保持其整體的數據關聯性，這個對於壓測的准確度和參考性也很重要。
3.2 風險
測試環境的風險主要體現在跟生產的差異度，測試結果的參考價值會打一定程度的折扣，可以視自身情況選擇合理的方式，比如看重入口網絡的檢驗的，可以測試環境和生產環境共享入口。對測試環境系統平台、中間件、數據庫等不熟悉和了解，也會導致瓶頸不易分析、不易調優等。
3.3 測試環境預研
測試環境調研，需要調研如下內容：
-
系統架構：系統如何組成的，每一層功能是做什么的，與生產環境有多大差異，主要為后面進行瓶頸分析服務和生產環境性能評估，這個很重要。
-
操作系統平台：操作系統是哪種平台，進行工具監控。
-
中間件：哪種中間件，進行工具監控和瓶頸定位。
-
數據庫：哪種數據庫，進行工具監控和瓶頸定位。
-
應用：啟動多少個實例，啟動參數是多少，進行問題查找和瓶頸定位。
3.4 測試環境搭建
在熟知以上問題的前提下，測試環境搭建應盡量滿足如下規范：
-
測試環境架構與生產環境架構完全相同
-
測試環境機型與生產環境機型盡量相同，雲化的資源確保是同規格ECS或者容器
-
測試環境軟件版本與生產環境軟件版本完全相同，版本主要包括：操作系統、中間件相關、數據庫、應用等
-
測試環境參數配置與生產環境完全相同，參數主要包括：操作系統參數、中間件參數、數據庫參數、應用參數
-
測試環境基礎數據量與生產環境基礎數據量需在同一個數量級上。
-
只能減少測試環境機器台數，並且需要同比例縮小，而不能只減少某一層的機器台數。
-
理想的測試環境配置是生產環境的1/2，1/4。
4. 測試指標
4.1 分析
詳細的測試指標，可參考：性能專題：一文搞懂性能測試常見指標
一般來說，會將測試指標分為：業務指標、資源指標、應用指標、前端指標。
-
業務指標：如：並發用戶數、TPS（每秒處理請求數）、成功率、響應時間。
-
資源指標：如：CPU資源利用率、內存利用率、I/O、內核參數(信號量、打開文件數)等。
-
應用指標：如：空閑線程數、數據庫連接數、GC/FULL GC次數、函數耗時等。
-
前端指標：如：頁面加載時間，網絡時間（DNS，連接時間、傳輸時間等）。
4.2 風險
不同用戶對指標類型和期望值是不一樣的，需要提前針對不同角色的人員進行指標調研，設定閾值，測試出系統在閾值下的性能，瓶頸定位及調優。未提前關注測試指標，將會導致測試結果不是相關人員需要的，結果是無效的。
不同用戶對指標類型和期望值是不一樣的，需要提前針對不同角色的人員進行指標調研，設定閾值，測試出系統在閾值下的性能，瓶頸定位及調優。未提前關注測試指標，將會導致測試結果不是相關人員需要的，結果是無效的。
4.3 業務指標
業務響應時間(Response Time)：這個指標所有相關人員都明白其含義，業務部門更需要此指標的具體值，一般情況下，不同系統的業務響應時間期望值是不同的，１秒以內最佳；像淘寶系統業務ＲＴ基本在幾十毫秒以內。
業務處理能力（Transaction Per Second）: 這個指標是衡量系統的處理能力的一個非常重要的指標，TPS可以參照同行業系統和結合具體業務，中小企業TPS值為50~1000筆/秒，銀行TPS值為1000~50000筆/秒，淘寶TPS值為30000~300000筆/秒。
成功率: 這個指標是衡量系統處於壓力下，業務的成功率，一般業界成功率要大於99.6%。
4.4 資源指標
一般情況下，系統資源指標也不能超過瓶頸值，例如CPU資源利用率<=75%,內存無SWAP, 磁盤和網絡I/O不能自身處理能力。理想的情況下，當系統壓力上不去的時候，資源成為瓶頸（正常情況下，非其他瓶頸情況下導致），這樣的話加資源，系統處理能力還會上升的，但是遺憾的是，很多系統性能測試資源都沒達到瓶頸的時候，壓力就上不去了。
5. 業務模型
5.1 分析
系統有很多業務，每種業務邏輯和業務量是不一樣的，消耗系統的資源也不一樣，因此業務種類、業務占比決定了系統的處理能力，業務模型在性能測試中起着關鍵性的作用。以電商場景為例，不同的促銷形式和主推的類目決定了不同的容量整體配比，那么精准地將流量落地在PTS上進行壓測拿到系統的木桶最短板可以更好的利用機器資源達到業務目的。
5.2 風險
業務模型中業務和占比選取不對，跟生產差異非常大，直接導致測試結果沒有任何參考價值，並且容易誤導對系統處理能力的判斷。有些業務的業務量雖然占比很低，但一旦突變，對系統也是致命的，這些業務在性能測試中也需要關注。
5.3 規范
系統中的典型業務如何選取一般情況下遵循的規則是選取業務量高的、經常使用的、有風險的、未來有增長趨勢的業務作為系統的典型業務。已經上線的系統可以通過高峰時段歷史業務量和生產問題性能來評估，對於即將上線的系統可以通過調研和單交易資源消耗的結果來評估。
5.4 已上線系統
-
搜集生產上不同高峰時間段的業務種類和業務量，每個時間段的業務種類和業務量是否有很大的差異，如有的話，必須有多個業務模型；差異不大的，可以只用一個業務模型。
-
搜集生產上高峰時間段資源消耗和資源異常的時間點，從中捕獲資源消耗高和異常的原因，可能是由於某種”不起眼”的業務導致。
-
搜集生產問題，進行分析，如果是由於某種業務導致而且以前性能測試的時候忽略此筆業務，那么這筆業務的風險是非常大的，需要后續性能測試將此業務加入到業務模型中。
5.5 未上線系統
-
通過調研，確定業務種類和業務占比
-
通過調研，確定是否在業務促銷等活動中，某些業務有突變的可能。
-
通過測試結果，確定每筆業務的資源消耗，如果某些業務雖然占比低，但資源消耗非常大，那么需要適當的調整此業務占比。
6. 數據量
6.1 分析
數據量主要包括基礎數據量（或者叫歷史數據量、墊底數據量、數據庫中已有的數據量）和參數化數據量，數據量在性能測試中起到非常重要的作用。對於在數據庫中只有幾條記錄和有幾億條記錄里面查詢信息，那么結果肯定相差非常大的，隨着業務量的增長，記錄也越來越多，因此使用性能測試環境時，需要保持跟生產上相同級別的數據量；如果采用在生產環境中插入測試賬戶的方式，可以一定程度解決環境真實性和基礎數據量同量級的問題。阿里全鏈路壓測的方式對於基礎數據量的要求和上述類似。然后，我們在測試的時候需要考慮參數數據量的大小和數據分布的問題。
6.2 風險
如果基礎數據量跟生產環境的基礎數據量不在同一個數量級上，將會導致相關指標例如響應時間比生產上快很多，不真實，甚至導致測試結果沒有參考意義。如果參數化數據量過少、未考慮數據分布的情況，將會導致測試結果不真實，甚至測試結果沒有參考意義。生產環境中插入測試賬戶的方式，需要考慮數據准備的完整性問題，還有清理的邏輯需要完整。全鏈路壓測的方式需要投入較大的改造成本，同時包括后續的持續迭代維護。
6.3 基礎數據量
如果是測試環境，基礎數據量需要跟生產環境基礎數據量保持在同一個數據量級上，一般情況下需要考慮未來三年數據量增長趨勢，如果增長過快需要在測試環境造非常多的數據。
6.4 參數化數據量
-
參數化數據量盡可能的多，必要的情況下，可以清除緩存或者用寫代碼的方式提供參數化。
-
參數化數據分布，如果業務有明顯的地域等分布的特征，需要考慮數據分布的情況。
7. 測試類型
7.1 分析
測試類型主要分為負載測試、壓力測試、單交易基准測試、混合交易負載測試（容量測試）、混合交易穩定性測試、混合交易可靠性測試、批量測試等。每種測試類型針對不同的目的，可以根據生產系統現實情況進行選擇。
7.2 風險
缺少某種測試類型，將會導致現實生產系統某種場景沒有測到，發生風險，例如：系統崩潰、響應時間慢等。
7.3 規范
如果時間充足，建議大部分測試類型都需要測試一下，也可以參考以下規范：
-
單交易基准測試：可選
-
單交易負載測試：可選，未上線系統建議做負載，看資源消耗
-
混合交易負載測試（容量測試）：必須
-
混合交易壓力測試：可選
-
混合交易穩定性測試：必須
-
混合交易可靠性測試：可選
-
批量測試：可選
-
批量測試對混合交易影響測試：可選
8. 串聯鏈路
8.1 分析
串聯鏈路是指一組含有某種業務含義的壓測 API 的有序集合（類似事務），串聯鏈路是用來模擬用戶側的業務操作，模擬的正確與否直接影響着系統的性能，模擬業務操作的時候，需要參數化數據。
8.2 風險
業務沒有做成功或業務邏輯與實際生產環境差距太大將會導致測試結果沒有參考價值。
8.3 規范
-
跟生產上業務規則一致編排串聯鏈路。
-
在關鍵地方校驗服務器返回值，為壓測API（指一條由用戶行為觸發的端上請求）添加斷言。
-
數據盡量參數化、數據量盡可能的多。
9. 場景
9.1 分析
壓測場景是若干個基於 HTTP/HTTPS 的 URL/API 的組合，用於模擬現實生產環境中業務場景，包括施壓模式、壓力遞增方式、運行時間等。場景模擬需要跟生產上場景相一致，特別是在一段時間內，測試出來的各業務TPS占比跟生產上高峰時候業務占比一致。
9.2 風險
場景的風險主要體現在測試出來的業務TPS占比需跟生產上業務占比一致，在業務比例偏離嚴重的情況下，將會導致測試結果不真實或者無效，不能反映生產上的業務場景。
9.3 規范
測試結果中各業務TPS占比需跟生產上業務占比（業務模型）相一致，如何才能保證一致呢？可以使用PTS特有的RPS模式（Request Per Second，直接測試吞吐能力）：例如：A和B兩筆業務，占比為1：4，響應時間分別為1ms,100ms,那么只需要通過PTS給A和B兩個接口按照1：4比例設置請求數（TPS）施壓即可；如果使用傳統的並發模式，A和B的並發需要經過換算確保比例是1:400,使得最終與生產上保持一致的業務模型。
10. 監控
10.1 分析
監控的目的主要是為進行性能測試分析服務的，完善的對系統進行監控，針對瓶頸定位起到”事半功倍”的效果。一般來說，需要針對操作系統、中間件、數據庫、應用等進行監控，每種類型的監控盡量指標全面。
10.2 風險
沒有完善的系統監控，將會導致性能分析無從下手，定位不出系統瓶頸，根本不知道從哪進行調優。
10.3 規范
操作系統：CPU(User,Sys,Wait,Idle)利用率，內存利用率(包括Swap),磁盤I/O,網絡I/O，內核參數等
中間件：線程池、JDBC連接池、JVM（GC/FULL GC/堆大小）
數據庫: 效率低下SQL、鎖、緩存、會話、進程數等
應用：方法耗時、同步與異步、緩沖、緩存
一般可以配合APM工具（如ARMS）進行中間件、數據庫、應用層面的問題定位。
11. 瓶頸分析
11.1 分析
瓶頸定位的目的是對系統中存在的瓶頸點進行分析，為調優做准備，系統的性能瓶頸點主要分布在操作系統系統資源、中間件參數配置、數據庫問題以及應用算法上，對於有針對性的進行調優，有利於系統性能的提升。
11.2 風險
當系統的瓶頸點不能被分析出來以后，新業務上線或者核心業務就存在風險，這種風險有可能導致業務高峰的時候，系統性能體驗差，甚至“崩潰”。
11.3 規范
分析系統的瓶頸點遵循的規則如下：
-
操作系統資源消耗：CPU、Memory、Disk I/O、Network I/O
-
中間件指標：線程池(Thread Pool)、數據庫連接池(JDBC)、JVM(GC/FULL GC/堆大小)
-
數據庫指標：效率低下SQL、鎖等待/死鎖、緩存命中率、會話、進程等
-
應用：方法耗時、算法、同步和異步、緩存、緩沖
-
壓力機：壓力機資源消耗，一般情況下，壓力機成為瓶頸的可能性非常低。PTS壓力機有保護和調度機制不用單獨關注。
12. 調優
12.1 分析
調優的目的是提升系統的性能，針對系統的“瓶頸點”對症“下葯”,通過測試驗證系統的性能有多大的提升。
11.2 風險
未進行調優的系統，系統上線后，可能會出現客戶體驗差的效果，甚至導致系統“崩潰”的風險。
11.3 規范
系統調優遵循的規則如下：
-
中間件調優：線程池、數據庫連接池、JVM。
-
數據庫調優：效率低下SQL、死鎖和鎖等待、緩存命中率，進程和會話參數。
-
應用調優：方法耗時、算法、同步和異步、緩存、緩沖。
-
系統資源：一般情況下，系統資源(CPU\大部分是由應用和參數設置不合理導致的，並非系統資源真的不夠”用”。
更多更優質的資訊，請關注我，你們的支持會鼓勵不斷產出分享更多更好的優質文章，最后，公號「測試開發技術」后台回復me， 免費領取全棧工程師進階高清圖譜。