術語定義

• 并發用戶：在性能測試工具中，一般稱為虛擬用戶（Virtual User，簡稱VU），指的是現實系統中操作業務的用戶。
  說明 并發用戶與注冊用戶、在線用戶不同。注冊用戶一般指的是數據庫中存在的用戶。在線用戶只是“掛”在系統上，對服務器不產生壓力。但并發用戶一定會對服務器產生壓力。
• TPS：Transaction Per Second，每秒事務數，是衡量系統性能的一個非常重要的指標。
  說明 系統每秒處理事務數越多證明您的機器性能越好。
• RPS：Request Per Second，每秒請求數。RPS模式適合用于容量規劃和作為限流管控的參考依據。
• RT：Response Time，響應時間，指的是業務從客戶端發起到客戶端接收的時間。

在性能測試中，通常有兩種施壓模式：并發模式和RPS模式。傳統方式是使用并發用戶數來衡量系統的性能（站在客戶端視角）。此方法一般適用于一些網頁站點的壓測（例如H5頁面）；而RPS（Requests per second）模式主要是為了方便直接衡量系統的吞吐能力TPS（Transaction Per Second，每秒事務數）而設計的（站在服務端視角），按照被壓測端需要達到TPS等量設置相應的RPS，應用場景主要是一些動態的接口API，例如登錄、提交訂單等等。

VU和TPS換算

公式描述：TPS=VU/RT，（RT單位：秒）。

舉例說明：假如1個虛擬用戶在1秒內完成1筆事務，那么TPS明顯就是1。如果某筆業務響應時間是1 ms，那么1個虛擬用戶在1s內能完成1000筆事務，TPS就是1000了；如果某筆業務響應時間是1s，那么1個虛擬用戶在1s內只能完成1筆事務，要想達到1000 TPS，就需要1000個虛擬用戶。因此可以說1個虛擬用戶可以產生1000 TPS，1000個虛擬用戶也可以產生1000 TPS，無非是看響應時間快慢。

如何獲取VU和TPS

• VU獲取方式：

  已有系統：可選取高峰時刻，在一定時間內使用系統的人數，這些人數可認為是在線用戶數，并發用戶數可以取10%，例如在半個小時內，使用系統的用戶數為10萬，那么取10%（即1萬）作為并發用戶數基本就夠了。

  新系統：沒有歷史數據作參考，建議通過業務部門進行評估。

• TPS獲取方式：

  已有系統：可選取高峰時刻，在一定時間內（如3分鐘~10分鐘），獲取系統總業務量，計算單位時間（秒）內完成的筆數，乘以2~5倍作為峰值的TPS，例如峰值3分鐘內處理訂單18萬筆，平均TPS是1000，峰值TPS可以是2000~5000。

  新系統：沒有歷史數據作參考，建議通過業務部門進行評估。

如何評價系統的性能

針對服務器端的性能，以TPS為主來衡量系統的性能，并發用戶數為輔來衡量系統的性能，如果必須要用并發用戶數來衡量的話，需要一個前提，那就是交易在多長時間內完成，因為在系統負載不高的情況下，將思考時間（思考時間的值等于交易響應時間）加到串聯鏈路中，并發用戶數基本可以增加一倍，因此用并發用戶數來衡量系統的性能沒太大的意義。同樣的，如果系統間的吞吐能力差別很大，那么同樣的并發下TPS差距也會很大。

性能測試策略

做性能測試需要一套標準化流程及測試策略。在做負載測試的時候，傳統方式一般都是按照梯度施壓的方式去加用戶數，避免在沒有預估的情況下，一次加幾萬個用戶，導致交易失敗率非常高，響應時間非常長，已經超過了使用者忍受范圍內；較為適合互聯網分布式架構的方式，也是阿里巴巴的最佳實踐是用TPS模式（吞吐量模式）+設置起始和目標最大量級，然后根據系統表現靈活的手工實時調速，效率更高，服務端吞吐能力的衡量一步到位。更多信息，請參見如何設置目標并發或目標RPS？。

總結

綜上所述，可以得出以下結論：

• 系統的性能由TPS決定，跟并發用戶數沒有多大關系。
• 系統的最大TPS是一定的（在一個范圍內），但并發用戶數不一定，可以調整。
• 建議性能測試的時候，不要設置過長的思考時間，以最壞的情況下對服務器施壓。
• 一般情況下，大型系統（業務量大、機器多）做壓力測試，10000~50000個用戶并發，中小型系統做壓力測試，5000個用戶并發比較常見。