如果你對效能測試感興趣，但是又不熟悉理論知識，可以看下面的系列文章
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講》，因為指標那一塊講的特別好哦~