併發虛擬用戶、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個腳本

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

  那麼第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個用戶併發比較常見。