性能專題：性能測試實施全過程指南

閱讀全文需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， 免費領取全棧工程師進階高清圖譜。