性能測試中TPS和併發用戶數

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能夠幫助開發者經過分佈式併發壓力測試，模擬指定區域和指定數量的用戶同時訪問，提早預知網站承載力。這就是雲計算給咱們帶來的便利。