1. 背景

在做效能測試的時候，很多人都用併發使用者數來衡量系統的效能，覺得系統能支撐的併發使用者數越多，系統的效能就越好；對TPS不是非常理解，也根本不知道它們之間的關係，因此非常有必要進行解釋。

2. 術語定義

Ø 併發使用者數：指的是現實系統中操作業務的使用者，在效能測試工具中，一般稱為虛擬使用者數(Virutal User)，注意併發使用者數跟註冊使用者數、線上使用者數有很大差別的，併發使用者數一定會對伺服器產生壓力的，而線上使用者數只是 ”掛” 在系統上，對伺服器不產生壓力，註冊使用者數一般指的是資料庫中存在的使用者數。

Ø TPS：Transaction Per Second, 每秒事務數, 是衡量系統效能的一個非常重要的指標，

3. 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=

4. 如何獲取Vu和TPS

Ø 併發使用者數(Vu)獲取

新系統：沒有歷史資料作參考，只能通過業務部門進行評估。

舊系統：對於已經上線的系統，可以選取高峰時刻，在一定時間內使用系統的人數，這些人數認為屬於線上使用者數，併發使用者數取10%就可以了，例如在半個小時內，使用系統的使用者數為10000，那麼取10%作為併發使用者數基本就夠了。

Ø TPS獲取

新系統：沒有歷史資料作參考，只能通過業務部門進行評估。

舊系統：對於已經上線的系統，可以選取高峰時刻，在5分鐘或10分鐘內，獲取系統每筆交易的業務量和總業務量，按照單位時間內完成的筆數計算出TPS，即業務筆數/單位時間（5*60或10*60）

5. 如何評價系統的效能

針對伺服器端的效能，以TPS為主來衡量系統的效能，併發使用者數為輔來衡量系統的效能，如果必須要用併發使用者數來衡量的話，需要一個前提，那就是交易在多長時間內完成，因為在系統負載不高的情況下，將思考時間(思考時間的值等於交易響應時間)加到指令碼中，併發使用者數基本可以增加一倍，因此用併發使用者數來衡量系統的效能沒太大的意義。

6. 相關案例

通過大量效能測試我們發現不需要用上萬的使用者併發去進行測試，只要系統處理業務時間足夠快，幾百個使用者甚至幾十個使用者就可以達到目的。另外諮詢很多專家做過的效能測試專案，基本都沒有超過5000使用者併發。

因此對於大型系統、業務量非常高、硬體配置足夠多的情況下，5000使用者併發就足夠了；對於中小型系統，1000使用者併發就足夠了。

7. 效能測試策略

做效能測試需要一套 標準化流程及測試策略，併發使用者數只是指標考慮的一個，在做負載測試的時候，一般都是按照梯度施壓的方式去加使用者數，而不是在沒有預估的情況下，一次加幾 萬個使用者，，交易失敗率非常高，響應時間非常長，已經超過了使用者忍受範圍內，這樣做沒有多大的意義，這就好比“有多少錢可以幹多少事”一樣，需要選擇相 關的策略。