併發虛擬用戶、RPS、TPS的解讀

在作性能測試的時候,傳統方式都是用併發虛擬用戶數來衡量系統的性能(站在客戶端視角),通常適用於一些網頁站點好比首頁、H5 的壓測;而 RPS(Requests per second)模式主要是爲了方便直接衡量系統的吞吐能力-TPS(Transaction Per Second, 每秒事務數)而設計的(站在服務端視角),按照被壓測端須要達到TPS等量設置相應的RPS,應用場景主要是一些動態的接口API,好比登錄、提交訂單等等。數據庫

VU(虛擬用戶)和TPS之間也有其邏輯關係。具體請看下方的說明。服務器

術語定義

  • 併發用戶數:簡稱VU ,指的是現實系統中操做業務的用戶,在性能測試工具中,通常稱爲虛擬用戶數(Virutal User),注意併發用戶數跟註冊用戶數、在線用戶數有很大差異的,併發用戶數必定會對服務器產生壓力的,而在線用戶數只是 」掛」 在系統上,對服務器不產生壓力,註冊用戶數通常指的是數據庫中存在的用戶數。
  • 處理能力:簡稱TPS, 每秒事務數, 是衡量系統性能的一個很是重要的指標。
  • 響應時間:簡稱RT,指的是業務從客戶端發起到客戶端接受的時間。

VU 和 TPS 換算

  • 簡單例子:在術語中解釋了TPS是每秒事務數,可是事務時要靠虛擬用戶作出來的,假如1個虛擬用戶在1秒內完成1筆事務,那麼TPS明顯就是1;若是某筆業務響應時間是1ms,那麼1個用戶在1秒內能完成1000筆事務,TPS就是1000了;若是某筆業務響應時間是1s,那麼1個用戶在1秒內只能完成1筆事務,要想達到1000TPS,至少須要1000個用戶;所以能夠說1個用戶能夠產生1000TPS,1000個用戶也能夠產生1000TPS,無非是看響應時間快慢。架構

  • 複雜公式:試想一下複雜場景,多個腳本,每一個腳本里面定義了多個事務(例如一個腳本里面有100個請求,咱們把這100個連續請求叫作Action,只有第10個請求,第20個請求分別定義了事務10和事務20)具體公式以下:併發

    符號表明意義:分佈式

    Vui表示的是第i個腳本使用的併發用戶數工具

    Rtj表示的是第i個腳本第j個事務花費的時間,此時間會影響整個Action時間性能

    Rti表示的是第i個腳本一次完成全部操做的時間,即Action時間測試

    n 表示的是第n個腳本ui

    m 表示的是每一個腳本中m個事務spa

    那麼第j個事務的 TPS = Vui/Rti

    總的TPS=

 如何獲取 VU 和 TPS

  • 併發用戶數(VU)獲取方式:

已有系統:可選取高峯時刻,在必定時間內使用系統的人數,這些人數可認爲是在線用戶數,併發用戶數能夠取10%,例如在半個小時內,使用系統的用戶數爲10萬,那麼取10%(即1萬)做爲併發用戶數基本就夠了。

新系統:沒有歷史數據做參考,建議經過業務部門進行評估。

  • TPS獲取方式:

已有系統:可選取高峯時刻,在必定時間內(如3-10分鐘),獲取系統總業務量,計算單位時間(秒)內完成的筆數,乘以2-5倍做爲峯值的TPS,例如峯值3分鐘內處理訂單18萬筆,平均TPS是1000,峯值TPS能夠是2000-5000。

新系統:沒有歷史數據做參考,建議經過業務部門進行評估。

如何評價系統的性能

針對服務器端的性能,以TPS爲主來衡量系統的性能,併發用戶數爲輔來衡量系統的性能,若是必需要用併發用戶數來衡量的話,須要一個前提,那就是交易在多長時間內完成,由於在系統負載不高的狀況下,將思考時間(思考時間的值等於交易響應時間)加到串聯鏈路中,併發用戶數基本能夠增長一倍,所以用併發用戶數來衡量系統的性能沒太大的意義。一樣的,若是系統間的吞吐能力差異很大,那麼一樣的併發下TPS差距也會很大。

性能測試策略

作性能測試須要一套標準化流程及測試策略。在作負載測試的時候,傳統方式通常都是按照梯度施壓的方式去加用戶數,避免在沒有預估的狀況下,一次加幾萬個用戶,致使交易失敗率很是高,響應時間很是長,已經超過了使用者忍受範圍內;較爲適合互聯網分佈式架構的方式,也是阿里的最佳實踐是用TPS模式(吞吐量模式)+設置起始和目標最大量級,而後根據系統表現靈活的手工實時調速,效率更高,服務端吞吐能力的衡量一步到位。

總結

  • 系統的性能由TPS決定,跟併發用戶數沒有多大關係。
  • 系統的最大TPS是必定的(在一個範圍內),但併發用戶數不必定,能夠調整。
  • 建議性能測試的時候,不要設置過長的思考時間,以最壞的狀況下對服務器施壓。
  • 通常狀況下,大型系統(業務量大、機器多)作壓力測試,10000~50000個用戶併發,中小型系統作壓力測試,5000個用戶併發比較常見。
相關文章
相關標籤/搜索