1. 程式人生 > >大話效能測試系列(3)- 常用的效能指標

大話效能測試系列(3)- 常用的效能指標

如果你對效能測試感興趣,但是又不熟悉理論知識,可以看下面的系列文章

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講》,因為指標那一塊講的特別好哦~

&n