如果你對性能測試感興趣，但是又不熟悉理論知識，可以看下面的系列文章
https://www.cnblogs.com/poloyy/category/1620792.html
兩種性能指標
- 業務指標
- 技術指標
通常我們會從兩個層面定義性能場景的需求指標，它們有映射關係，技術指標不能脫離業務指標
併發
狹義
指同一個時間點執行相同的操作（如：秒殺）
廣義
- 同一時間點，向服務器發起的請求（可能是不同的請求）
- 只要向服務器發起請求，那麼服務器在這一時間點內都會收到請求（不管是不是同一個請求）
場景類比
高速公路上，同時有多少輛車經過同一個關卡，但不一定是同一個牌子的汽車
併發用戶數（重點）
同一時間點，發出請求的用戶數，一個用戶可以發出多個請求
和併發的關係
假設有 10 個用戶數，每個用戶同一時間點內發起 2 個請求，那麼服務器收到的請求併發數就是 20
相關概念
- 系統用戶數：系統累計註冊用戶數，不一定在線
- 在線用戶數：在線用戶可能是正常發起請求，也可能只是掛機啥操作都沒有【在線用戶數≠併發用戶數】
- 線程數：在 jmeter 中，線程數和併發用戶數等價
事務
- 客戶端向服務器發送請求，然後服務器做出響應的過程
- 登錄、註冊、下單等功能都屬於一個事務
- 一個事務可能會發起多個請求
jmeter 相關
jmerter 中，默認一個接口請求，就是一個事務；但也支持多個接口整合成一個事務
注意點
若一個業務或事務有多個接口，那麼多個單接口的性能指標值相加 ≠ 業務或事務的性能指標值
再來看看有哪些常見的性能指標值
響應時間（Respose Time）
概念：從發起請求到收到請求響應的時間
包含：Request Time 和 Response Time
等價：發起請求網絡傳輸時間 + 服務器處理時間 + 返迴響應網絡傳輸時間
重點
在做性能測試時，要盡可能的降低網絡傳輸時間，這樣最終得出的 RT 會無限接近服務器處理時間，所以我們要把網絡環境搞好
事務請求響應時間
完成單個事務所用的時間，可能包含了多個請求
TPS（Transaction Per Second，最主要的指標）
服務器每秒處理事務數，衡量服務器處理能力的最主要指標
知道 T 是如何定義的
- 在不同的行業、業務中，TPS 定義的顆粒度可能是不同的
- 所以不管什麼情況下，需要做性能測試的業務的相關方都要知道你的 T 是如何定義的
定義 TPS 的粒度
- 一般會根據場景的目的來定義 TPS 的粒度
- 接口層性能測試：T 可以定義為接口級
- 業務級性能測試：T 可以定義為每個業務步驟和完整的業務流
栗子
如果要單獨測試接口 1、2、3，那麼 T 就是接口級
如果從用戶角度下訂單，那 1、2、3 都在一個 T 中，就是業務級
結合實際業務設計，庫存服務一定是同步，而積分服務可以是異步，所以這個下單業務，可以只看作由 1、2 這兩個接口組成，但是 3 接口還是要監控分析的
所以，性能中 TPS 中 T 的定義取決於場景的目標和 T 的作用
拿上圖做個例子
接口級腳本
——事務 start（接口 1）
接口 1 腳本
——事務 end（接口 1）
——事務 start（接口 2）
接口 2 腳本
——事務 end（接口 2）
——事務 start（接口 3）
接口 3 腳本
——事務 end（接口 3）
業務級接口層腳本（就是用接口拼接出一個完整的業務流）
——事務 start（業務 A）
接口 1 腳本 – 接口 2（同步調用）
接口 1 腳本 – 接口 3（異步調用）
——事務 end（業務 A）
用戶級腳本
——事務 start（業務 A）
點擊 0 – 接口 1 腳本 – 接口 2（同步調用）
點擊 0 – 接口 1 腳本 – 接口 3（異步調用）
——事務 end（業務 A）
總結
一般情況下，我們會按從上到下的順序一一來測試，這樣路徑清晰地執行，容易定位問題
QPS（Queries per Second）
- 每秒查詢率，在數據庫中每秒執行 SQL 數量
- 一個請求可能會執行多條 SQL
- 某些企業可能會用QPS代替TPS
- 也是衡量服務端處理能力的一個指標，但不建議使用
RPS（Request per Second）
簡單理解
每秒請求數，用戶從客戶端發起的請求數
深入挖掘
對於請求數來說，也要看是哪個層面的請求，把上面的圖做一點點變化來描述請求數
如果一個用戶點擊了一次，發出來 3 個 HTTP Request，調用了 2 次訂單服務，調用了 2 次庫存服務，調用了 1 次積分服務
問：Request 數量如何計算
答：3+2+2+1 = 8？不， 應該是 3，因為發出了 3 個 Request，而調用服務會有單獨的描述，以便做性能統計
HPS（Hit per Second）
- 點擊率，每秒點擊數
- 有直接理解為用戶在界面上的點擊次數
- 一般在性能測試中，都用來描述 HTTP Request，那它代表每秒發送 HTTP 請求的數量，和 RPS 概念完全一樣
- HPS 越大對 Server 的壓力越大
CPS/CPM（Calls Per Second/ Calls Per Minutes）
- 每秒/每分鐘調用次數
- 通常用來描述 Service 層的單位時間內被其他服務調用的次數
栗子
上圖的訂單服務、庫存服務、積分服務，各調用了2、2、1次，還是比較好理解的
TPS、QPS、RPS、HPS、CPS 的總結
有很多維度可以衡量一個系統的性能能力，但是如果把五個指標同時都拿來描述系統性能能力的話，未必太混亂了
為此我們可以這樣做
- 用 TPS 來統一形容系統的性能能力，其他的都在各層面加上限制條件來描述，比如說：接口調用 1000 Calls/s
- 在團隊中要定義清楚術語的使用場景，還有含義
吞吐量（Throughput）
單位時間內，網絡處理的請求數量（事務/s）
網絡沒有瓶頸時，吞吐量≈TPS
吞吐率
單位時間內，在網絡傳輸的數據量的平均速率（kB/s）
資源利用率
- 服務器資源的使用程度，比如服務器（應用、服務器）的CPU利用率，內存利用率，磁盤利用率，網絡帶寬利用率
- 一般不超過80%
結尾
本篇博文，部分參考了高老師的《性能測試實戰30講》，因為指標那一塊講的特別好哦~
本站聲明:網站內容來源於博客園,如有侵權,請聯繫我們,我們將及時處理
【其他文章推薦】
※教你寫出一流的銷售文案?
※廣告預算用在刀口上，台北網頁設計公司幫您達到更多曝光效益
※回頭車貨運收費標準
※別再煩惱如何寫文案,掌握八大原則!
※超省錢租車方案
※產品缺大量曝光嗎?你需要的是一流包裝設計!