2021年底粉絲大饋贈，熬夜7天肝出這一份3000字性能測驗學習筆記

很多需要進階性能測驗的朋友，不知道性能測驗學習該如何開始，性能測驗需要掌握哪些知識，下面是根據本人的理解，粗略整理的一個學習大綱，基本上涵蓋了軟體測驗工程師需要掌握的全部技能，希望對想進階或者準備進階學習的朋友提供一點指引，

目錄

性能測驗

概念

性能指標

模型

性能測驗方案

性能監控

性能測驗要有預定的條件

性能測驗中要有場景

性能測驗的分析調優

TPS和回應之間（RT）是什么關系

性能指標

性能分析思路

性能場景設計

性能監控設計

全域監控設計

作業系統常用計數器

性能測驗

概念

• 性能測驗針對系統的性能指標，建立性能測驗模型，制定性能測驗方案，制定監控策略，在場景條件之下執行性能場景，分析判斷性能瓶頸并調優，最終得出性能結果來評估系統的性能指標是否滿足既定值，

性能指標

• 指標包括：時間指標、容量指標和資源利用率指標
  • 時間指標指的是介面回應時間、業務回應時間
  • 容量指標指的是介面容量、業務容量
  • 資源利用率指標指的是作業系統（CPU、IO、Mem、Disk、Network、System）、JVM等
• 指標的由來：可以是根據業務場景，同團隊成員商討獲得；或者實際執行壓測時沒有設定指標，目的設定為查看系統的性能瓶頸

模型

• 模型指的是真實場景的抽象，可以告訴性能測驗人員，業務模型是什么樣子
• 通俗的可以理解為，模型可以讓測驗人員知道具體業務的并發情況，方便測驗人員根據模型設計具體的壓力比例
• 模型資料的獲得：一般是從生產環境中統計得到（比如對各個節點打log,然后根據log來分析得到流量情況）

性能測驗方案

• 方案包含的內容：測驗環境、測驗資料、測驗模型、性能模型、壓力策略、準入準出和進度風險

性能監控

• 要有分層、分段的能力，要有全域監控、定向監控的能力

性能測驗要有預定的條件

• 這里的條件包括軟硬體環境、測驗資料、測驗執行策略、壓力補償等內容

性能測驗中要有場景

• 在既定的環境(包括動態擴展等策略)、既定的資料(包括場景執行中的資料 變化)、既定的執行策略、既定的監控之下，執行性能腳本，同時觀察系統各層級的性能狀 態引數變化，并實時判斷分析場景是否符合預期
• 場景分類：基準性能測驗、容量性能場景、穩定性性能場景、例外性能場景

性能測驗的分析調優

• 性能專案分類
  • 新系統性能測驗類:這樣的專案一般都會要求測驗出系統的最大容量
  • 舊系統新版本性能測驗類:這樣的專案一般都是和舊版本對比，只要性能不下降就可以 根據歷史資料推算容量，對調優要求一般都不大，
  • 新系統性能測驗優化類:這類的系統不僅要測驗出最大容量，還要求調優到最好，

性能測驗肯定要有結果報告

• 內容包含：調優前后的TPS、回應時間、資源對比圖

  

TPS和回應之間（RT）是什么關系

• 在實際的性能測驗中，假設以梯度遞增并發用戶數，那么一開始TPS是緩慢上升的，此時RT會有一段時間維持在較低的水平；隨著壓力繼續增大，TPS也會上升，RT也緩慢上升；當TPS達到極限，而壓力依舊繼續增大時，RT會極速上升，最后到達超時

性能指標

需求指標

• 業務指標
  • 業務層面的指標，如業務方要求1000萬在線用戶，那么繼續可以拆分為n個性能場景，每個性能場景中也有對應的定值的業務比例
• 技術指標
  • RT 回應時間（ReSponse Time），通常所說的回應時間，包含了Request Time和Response Time
  • HPS 每秒點擊數（Hit Per Second）
  • TPS 每秒事務數（Transactions Per Second）
  • QPS 在mysql中指每秒sql數
  • RPS 每秒請求數
  • CPS HTTP回傳碼每秒
  • PV 頁面瀏覽量
  • UV 獨立訪問者
  • IP 獨立IP數
  • Throughput 吞吐量
  • IOPS 通常描述磁盤

性能指標概念

• TPS

  • 需要根據場景來定義TPS的粒度；如果是介面層性能測驗，那么T是介面級；如果是業務級性能測驗，T 可以直接定義為每個業務步驟和完整的業務流，

• 并發用戶數

  • 絕對并發：同一時刻的并發數
  • 相對并發：一個時間段內的并發數
  • 用TPS來承載并發的概念

• 在線用戶數和并發用戶數

  • 在線用戶數指的是某段時間內在系統上的用戶，這些用戶并不一定會執行動作
  • 并發用戶數指定是上述的在線用戶某段時間內對某個服務進行動作時的用戶數目（并發用戶數 = 在線用戶數 * 并發度 ）

• 公式

  

性能分析思路

• 總體思路
  • 瓶頸的精準判斷
  • 執行緒遞增的策略
  • 性能衰減的程序
  • 回應時間的拆分
  • 構建分析決策樹
  • 場景的比對
• 瓶頸的精準判斷
  • TPS曲線

    

  • 假設執行緒是等比例遞增的，對于上面那個圖，我們可以看到在第二階梯已經出現性能瓶頸了，因為理論來說第二階梯的TPS應該是第一階梯的兩倍，然而實際并不是，所以出現了性能瓶頸
  • TPS的意義（從TPS曲線得到的資訊）
    • 有沒有瓶頸:其實準確說所有的系統都有性能瓶頸，只看我們在哪個量級在做性能測驗 了，
    • 瓶頸和壓力有沒有關系:TPS 隨著壓力的變化而變化，那就是有關系，不管壓力增不增 加，TPS 都會出現曲線趨勢問題，那就是無關，
  • 回應時間曲線
    • TPS曲線和回應時間曲線的著重點
      • 回應時間是用來判斷業務有多快的，而 TPS 才是用來判斷容量有多大的，

• 執行緒遞增的策略
  • 兩種執行緒遞增場景

    

    

  • 總結
    • 對一個系統來說，如果僅在改變壓力策略(其他的 條件比如環境、資料、軟硬體配置等都不變)的情況下，系統的最大 TPS 上限是固定的，
    • 關于秒殺場景的測驗，前期一定要做好預熱，預熱指的是有一定的流量在跑，然后在突增壓力，這樣的比較類似于實際場景；而不是直接一次就大流量進入系統，
• 性能衰減的程序
  • 只要每執行緒每秒的 TPS 開始變少，就意味著性能瓶頸已經出現了， 但是瓶頸出現之后，并不是說服務器的處理能力(這里我們用 TPS 來描述)會下降，應該 說 TPS 仍然會上升，在性能不斷衰減的程序中，TPS 就會達到上限，
• 回應時間的拆分

  

• 構建分析決策樹
  • 它是對架構的梳理，是對系統的梳理，是對問題的梳理，是對查找證據鏈程序的梳理，是對分析思 路的梳理，它起的是縱觀全域，高屋建瓴的指導作用，
• 場景的比對
  • 當你覺得系統中哪個環節不行的時候， 又沒能力分析它，你可以直接做該環節的增加，

引數化資料

• 引數化邏輯
  • 分析業務場景
  • 羅列出需要引數化的資料及相對應的關系
  • 將引數化資料從資料庫中取出或設計對應的生成規則
  • 合理地將引數化資料保存在不同的檔案中
  • 在壓力工具中設定相應的引陣列合關系，以便實作模擬真實場景

性能場景：做引數化之前需要考慮的內容

• 需要關注的資料
  • 引數化資料、監控資料和基礎鋪底資料

引數化資料

• 引數化資料可能出現的情況
  • 資料不均衡
  • 引數化資料量不足

引數化資料的疑問

• 引數化資料應該用多少資料量?

  

• 引數化資料從哪里來?

  • 引數化資料主要分為兩類
    • 用戶輸入的資料在后臺資料庫中已存在，比如我們上面示例中的用戶資料，
      • 資料特點：存在后臺資料庫中;需要用戶主動輸入;用戶輸入的資料會和后臺資料庫中的資料做比對，
      • 這類資料必須查詢資料庫之后再引數化到工具中，
    • 用戶輸入的資料在后臺資料庫中不存在，在業務流中，這些資料會 Insert 或 Update 到數 據庫中，
      • 資料特點：資料庫中原本不存在這些資料;在腳本執行成功后會將這些資料 insert 或 update 到資料庫中;每個用戶輸入的資料可能相同，也可能不同，這取決于業務特點，
      • 這類資料必須通過壓力工具做引數化，同時也必須滿足業務規則，
        • 資料滿足條件：要滿足生產環境中資料的分布;要滿足性能場景中資料量的要求，

• 引數多與少的選擇對系統壓力有什么影響?

  • 引數取得過多，對系統的壓力就會大;引數取得過少，不符合真實場景中的資料量，則無法 測驗出系統真實的壓力，

• 引數化資料在資料庫中的直方圖是否均衡?

  • 指的是每個用戶的資料分布是否符合業務場景；比如同樣是下單業務，給用戶A造了幾十萬資料，給用戶B造了幾條資料，明顯就是不合理的

性能場景設計

前期作業

• 確認需要壓測的業務，以及這些業務對應的業務比例（可以從日志中獲取）
• 確定業務目標TPS
• 確定業務目標回應時間

基準性能場景

• 目的
  • 為了測驗出單業務的最大容量，以便在混合容量場景 中判斷哪個業務對整體容量最有影響，

容量性能場景

• 要點
  • 場景不斷
  • 控制比例
• 容量TPS計算方法
  • 將各業務的TPS累加即可

穩定性性能場景

• 要點
  • 穩定性一般強調的是系統穩定跑一段時間，如要求2000w業務量在線上安全跑一周
  • 最小測驗時長 = 2000w / 容量TPS（這個值看容量性能場景的計算方式）

例外性能場景

• 測驗方法
  • 總的來說就是讓各種服務處于不穩定；比如主redis宕機，看redis切換時會不會導致功能問題

性能監控設計

監控設計步驟

• 分析系統的架構；針對各個組件進行監控
• 監控要有層次，要有步驟；先全域，后定向定量分析
• 通過分析全域、定向、分層的監控資料做分析，再根據分析的結果決定下一步要收集 什么資訊，然后找到完整的證據鏈

全域監控設計

中間件

• 訊息佇列

  • 指標包括：生產速度和消費速度
  • 假設發現rabittmq出現訊息堆積，解決辦法
    • 增加消費者（這種原因是消費速度跟不上生產速度）
    • 若增加消費者也不能解決，那么有可能是服務端出bug了，導致無法消費

• redis

  

• mysql

  

作業系統常用計數器

• 命令模塊

• CPU引數含義
  • us CPU 是用戶態行程消耗的 CPU 百分比
  • wa cpu是 I/O 讀寫等待消耗的 CPU 百分比，
  • sy CPU 是內核消耗的 CPU 百分比
  • si CPU 是軟中斷消耗的 CPU 百分比

下面是配套資料，對于做【軟體測驗】的朋友來說應該是最全面最完整的備戰倉庫，這個倉庫也陪伴我走過了最艱難的路程，希望也能幫助到你！

最后： 可以在公眾號：程式員小濠 ！ 免費領取一份216頁軟體測驗工程師面試寶典檔案資料，以及相對應的視頻學習教程免費分享！，其中包括了有基礎知識、Linux必備、Shell、互聯網程式原理、Mysql資料庫、抓包工具專題、介面測驗工具、測驗進階-Python編程、Web自動化測驗、APP自動化測驗、介面自動化測驗、測驗高級持續集成、測驗架構開發測驗框架、性能測驗、安全測驗等，

如果我的博客對你有幫助、如果你喜歡我的博客內容，請 “點贊” “評論” “收藏” 一鍵三連哦！喜歡軟體測驗的小伙伴們，可以加入我們的測驗技術交流扣扣群：310357728里面有各種軟體測驗資源和技術討論）