背景
在做性能測試的時候，傳統方式都是用並發虛擬用戶數來衡量系統的性能（站在客戶端視角），一般適用於一些網頁站點例如首頁、H5的壓測；而RPS（Requests per second）模式主要是為了方便直接衡量系統的吞吐能力TPS（Transaction Per Second，每秒事務數）而設計的（站在服務端視角），按照被壓測端需要達到TPS等量設置相應的RPS，應用場景主要是一些動態的接口API，例如登錄、提交訂單等等。
VU（虛擬用戶）和TPS之間也有其邏輯關系，具體請參見本文下方的說明。
術語定義
- jmeter的線程數就相當於並發用戶數，並發用戶數就是虛擬用戶數。
- 並發用戶數：簡稱VU，指的是現實系統中操作業務的用戶，在性能測試工具中，一般稱為虛擬用戶數（Virtual 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是一定的（在一個范圍內），但並發用戶數不一定，可以調整。
- 建議性能測試的時候，不要設置過長的思考時間，以最壞的情況下對服務器施壓。
- 一般情況下，大型系統（業務量大、機器多）做壓力測試，10000~50000個用戶並發，中小型系統做壓力測試，5000個用戶並發比較常見。