一、兩種性能指標
- 業務指標
- 技術指標
通常我們會從兩個層面定義性能場景的需求指標，它們有映射關系，技術指標不能脫離業務指標
二、並發
狹義
指同一個時間點執行相同的操作（如：秒殺）
廣義
- 同一時間點，向服務器發起的請求（可能是不同的請求）
- 只要向服務器發起請求，那么服務器在這一時間點內都會收到請求（不管是不是同一個請求）
三、並發用戶數（重點）
- 同一時間點，發出請求的用戶數，一個用戶可以發出多個請求
- 場景不一定是同一個
- 和 CPU、響應時間有關系
和並發的關系
假設有 10 個用戶數，每個用戶同一時間點內發起 2 個請求，那么服務器收到的請求並發數就是 20
性能測試小場景一
- 不同身份的用戶，訪問不同的頁面或發起不同的請求（廣義的並發）
- 觀察 CPU 使用率和響應時間
性能測試小場景二
- 所有用戶，同一個時間點發送同一個請求（狹義的並發）
- 觀察 CPU 使用率和響應時間
3.1 系統用戶數
- 系統累計注冊用戶數，不一定在線
- 注冊之后也可以一直不在線
- 因為用戶信息是存在數據庫的，而數據庫數據就是存在磁盤中，所以系統用戶數和磁盤空間有關系
3.2 性能測試小場景
- 寫一個腳本添加很多條用戶信息插入到數據庫
- 目的：測試系統容量，方便了解系統的最大容量
- 實際項目中，當系統容量接近最大容量時，系統需要進行容量擴容（加磁盤空間），否則就會爆掉
3.3 在線用戶數
- 在線用戶可能是正常發起請求，也可能只是掛機啥操作都沒有，不一定同時做某一件事情
- 在線用戶可能是游客（未注冊的用戶），也可能是系統用戶（已注冊的用戶）
- 在線用戶數
≠並發用戶數 - 和內存有關系
性能測試小場景
- 使用 Jmeter 讓不同的用戶不斷上線，且不下線和發起其他請求，看看內存使用情況
- 實際場景：12306 以前很多用戶在線，響應時間會拉的很長
3.4 線程數
在 jmeter 中，線程數和並發用戶數等價【和CPU、響應時間有關系】
四、事務
- 客戶端向服務器發送請求，然后服務器做出響應的過程
- 登錄、注冊、下單等功能都屬於一個事務
- 一個事務可能會發起多個請求
4.1 jmeter 相關
jmerter 中，默認一個接口請求，就是一個事務；但也支持多個接口整合成一個事務
4.2 注意點
若一個業務或事務有多個接口，那么多個單接口的性能指標值相加≠ 業務或事務的性能指標值
五、有哪些常見的性能指標值
| 簡寫 | 英文全稱 | 含義 |
|---|---|---|
| RT | Response Time | 響應時間。通常我們說的響應時間，都是包括了Request Time和Response Time |
| HPS | Hits Per Second | 每秒點擊數 |
| TPS | Transactions Per Second | 每秒事務數 |
| QPS | Queries Per Second | 在MySQL中指每秒SQL數 |
| RPS | Requests Per Second | 每秒請求數 |
| CPS | Codes Per Second | 在HTTP協議中，CPS偶有提及，指的是HTTP返回碼每秒 |
| PV | Page View | 頁面瀏覽量 |
| UV | Unique Vistor | 獨立訪問者 |
| IP | Internet Protocol | 本地是IP地址，子啊性能中一般指獨立IP數 |
| Throughput | / | 吞吐量 |
| IOPS | Input/Output Operations Per Second | 通常描述磁盤 |
六、響應時間（Respose Time）
6.1 響應時間對於性能測試來說
- 從發起請求到收到請求響應的時間
包含了：Request Time 和 Response Time等價於：發起請求網絡傳輸時間 + 服務器處理時間 + 數據庫系統處理時間 + 返回響應網絡傳輸時間
6.2 對用戶所感知的響應時間包括
- 用戶客戶端渲染時間（多了這個）
- 請求/響應數據網絡傳輸時間
- 應用服務器處理時間
- 數據庫系統處理時間
6.3 對用戶所感知的響應時間包括
- 用戶客戶端渲染時間（多了這個）
- 請求/響應數據網絡傳輸時間
- 應用服務器處理時間
- 數據庫系統處理時間
6.5 重點
在做性能測試時，要盡可能的降低網絡傳輸時間，這樣最終得出的 RT 會無限接近服務器處理時間，所以我們要把網絡環境搞好
6.6事務請求響應時間
完成單個事務所用的時間，可能包含了多個請求
6.7 假如用戶說應用很慢，要怎么分析？（僅供參考）
- 單個用戶慢？還是多個用戶慢？手上只有我們自己的應用慢？還是所有應用都這么慢？
- 網絡問題的話，帶寬是用哪家營業商？不同營業商是不是都卡？還是只有用戶所在的營業商卡？
- .....等等等
6.8 響應時間多少合理？
- 標准是：2、5、8
- 2秒：很好
- 5秒：可以接受
- 8秒：不能接受
七、TPS（Transaction Per Second，最主要的指標）
服務器每秒處理事務數，衡量服務器處理能力的最主要指標
7.1 知道 T 是如何定義的
- 在不同的行業、業務中，
TPS 定義的顆粒度可能是不同的 - 所以不管什么情況下，需要做性能測試的
業務的相關方都要知道你的T 是如何定義的
7.2 定義 TPS 的粒度
- 一般會
根據場景的目的來定義 TPS 的粒度 - 接口層性能測試：T 可以定義為接口級
- 業務級性能測試：T 可以定義為每個業務步驟和完整的業務流
如果要單獨測試接口 1、2、3，那么 T 就是接口級
如果從用戶角度下訂單，那 1、2、3 都在一個 T 中，就是業務級
結合實際業務設計，庫存服務一定是同步，而積分服務可以是異步，所以這個下單業務，可以只看作由 1、2 這兩個接口組成，但是 3 接口還是要監控分析的
所以，性能中 TPS 中 T 的定義取決於場景的目標和 T 的作用
7.3 拿上圖做個例子
接口級腳本
——事務 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）
9. 1 簡單理解
每秒請求數，用戶從客戶端發起的請求數
9. 2 深入挖掘
對於請求數來說，也要看是哪個層面的請求，把上面的圖做一點點變化來描述請求數
如果一個用戶點擊了一次，發出來 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 的總結
有很多維度可以衡量一個系統的性能能力，但是如果把五個指標同時都拿來描述系統性能能力的話，未必太混亂了
11.1 為此我們可以這樣做
- 用
TPS來統一形容系統的性能能力，其他的都在各層面加上限制條件來描述，比如說：接口調用 1000 Calls/s - 在團隊中要定義清楚
術語的使用場景，還有含義
十二、吞吐量（Throughput）
單位時間內，網絡處理的請求數量（事務/s）
網絡沒有瓶頸時，吞吐量≈TPS
十三、吞吐率
單位時間內，在網絡傳輸的數據量的平均速率（kB/s）
十四、 資源利用率
- 服務器資源的使用程度，比如服務器（應用、服務器）的CPU利用率，內存利用率，磁盤利用率，網絡帶寬利用率
- 一般不超過80%
Think Time 思考時間
從業務角度看
- 它指的是用戶進行操作時，每個請求之間的時間間隔
- 例子：加入購物車后，多久之后會點擊下單？瀏覽一個商品多久會加入購物車
從性能測試角度看
- 為了模擬用戶兩次操作之間的時間間隔，才有 Think Time，更加真實的模擬用戶的真是操作
- 它和用戶行為有關系，所以應該分析的是用戶行為而非用戶數