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. 性能測試策略
做性能測試需要一套標准化流程及測試策略，並發用戶數只是指標考慮的一個，在做負載測試的時候，一般都是按照梯度施壓的方式去加用戶數，而不是在沒 有預估的情況下，一次加幾萬個用戶，，交易失敗率非常高，響應時間非常長，已經超過了使用者忍受范圍內，這樣做沒有多大的意義，這就好比“有多少錢可以干 多少事”一樣，需要選擇相關的策略。
8. Loadrunner VS PTS
從下圖對比項可以看出，PTS比Loadrunner(LR)更能讓客戶接受。
| 方向 | 對比項 | Loadrunner | PTS | 備注 |
| 基礎設施 |
被測系統軟硬件環境需要額外購買？ | 需要 | 不需要 | 基礎設施軟硬件由阿里雲提供，只需要購買服務 |
| 壓力機環境需要額外購買？ | 需要 | 不需要 | 基礎設施軟硬件由PTS提供，只需要購買服務 | |
| 費用 |
費用 | 非常貴 | 便宜，按需收費 | 商業化工具License非常貴 |
| 功能 |
功能 | 強大 | 較強大 | LR很多功能基本上用不到，沒必要大馬拉小車 |
| 易用性 |
操作、學習等 | 困難 | 容易 | LR不易上手 |
| 穩定性 |
系統穩定性 | 較穩定 | 非常穩定 | LR壓測過程中經常出現莫名其妙錯誤 |
| 場景模擬 |
場景模擬條件 | 較真實 | 非常真實 | PTS分布在全國各地的分布式集群可以真實模擬出現實場景，而LR不太容易模擬，即使可以的話，控制機和壓力機通信經常掉線 |
9. 總結
Ø 系統的性能由TPS決定，跟並發用戶數沒有多大關系。在同樣的TPS下，可以由不同的用戶數去壓（通過加思考時間設置）。
Ø 系統的最大TPS是一定的（在一個范圍內），但並發用戶數不一定，可以調整。
Ø 建議性能測試的時候，不要設置過長的思考時間，以最壞的情況下對服務器施壓。
Ø 一般情況下，大型系統（業務量大、機器多）做壓力測試，5000個用戶並發就夠了，中小型系統做壓力測試，1000個用戶並發就足夠了。
性能測試中如何確定並發用戶數
並發用戶數：是指現實系統中操作業務的用戶，在性能測試工具中，一般稱為虛擬用戶數(Virutal User)。
並發用戶數和注冊用戶數、在線用戶數的概念不同，
並發用戶數一定會對服務器產生壓力的，
而在線用戶數只是 ”掛” 在系統上，對服務器不產生壓力，
注冊用戶數一般指的是數據庫中存在的用戶數。
TPS：Transaction Per Second, 每秒事務數, 是衡量系統性能的一個非常重要的指標。
作者認為現在很多從業人員在做性能測試時，都錯誤的認為系統能支撐的並發用戶數越多，系統的性能就越好。要理解這個問題，
首先需要了解TPS和並發用戶數之間的關系：
TPS就是每秒事務數，但是事務是基於虛擬用戶數的，假如1個虛擬用戶在1秒內完成1筆事務，那么TPS明顯就是1；如果 某筆業務響應時間是1ms,那么1個用戶在1秒內能完成1000筆事務，TPS就是1000了；如果某筆業務響應時間是1s,那么1個用戶在1秒內只能完 成1筆事務，要想達到1000TPS，至少需要1000個用戶；因此可以說1個用戶可以產生1000TPS，1000個用戶也可以產生1000TPS，無 非是看響應時間快慢。
也就是說，在評定服務器的性能時，應該結合TPS和並發用戶數，以TPS為主，並發用戶數為輔來衡量系統的性能。如果必須要用並發用戶數來衡量的 話，需要一個前提，那就是交易在多長時間內完成，因為在系統負載不高的情況下，將思考時間(思考時間的值等於交易響應時間)加到腳本中，並發用戶數基本可 以增加一倍，因此用並發用戶數來衡量系統的性能沒太大的意義。
作者最后做了綜述，他認為在性能測試時並不需要用上萬的用戶並發去進行測試，如果只需要保證系統處理業務時間足夠快，幾百個用戶甚至幾十個用戶就可 以達到目的。據他了解，很多專家做過的性能測試項目基本都沒有超過5000用戶並發。因此對於大型系統、業務量非常高、硬件配置足夠多的情況下，5000 用戶並發就足夠了；對於中小型系統，1000用戶並發就足夠了。
性能測試需要一套標准化流程及測試策略，在實際測試時我們還需要考慮其它方面的問題，比如如何模擬成千上萬來自不同地區用戶的訪問場景、如何選用合適的測試軟件。性能測試對一些小的團隊來說並非易事，不過前段時間阿里雲發布了性能測試服務PTS，PTS可以幫助開發者通過分布式並發壓力測試，模擬指定區域和指定數量的用戶同時訪問，提前預知網站承載力。這就是雲計算給我們帶來的便利。