效能測試中TPS和併發使用者數

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

øtps：transaction per second,每秒事務數, 是衡量系統效能的乙個非常重要的指標，

ø簡單例子：在術語中解釋了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獲取

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

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

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

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

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

從下圖對比項可以看出，pts比loadrunner(lr)更能讓客戶接受。

方向

對比項

loadrunner

pts

備註

基礎設施

被測系統軟硬體環境需要額外購買？

需要不需要

基礎設施軟硬體由阿里雲提供，只需要購買服務

壓力機環境需要額外購買？

需要不需要

基礎設施軟硬體由pts提供，只需要購買服務

費用費用

非常貴便宜，按需收費

商業化工具license非常貴

功能功能

強大較強大

lr很多功能基本上用不到，沒必要大馬拉小車

易用性操作、學習等

困難容易

lr不易上手

穩定性系統穩定性

較穩定非常穩定

lr壓測過程中經常出現莫名其妙錯誤

場景模擬

場景模擬條件

較真實非常真實

pts分布在全國各地的分布式集群可以真實模擬出現實場景，而lr不太容易模擬，即使可以的話，控制機和壓力機通訊經常掉線

ø  系統的效能由tps決定，跟併發使用者數沒有多大關係。在同樣的tps下，可以由不同的使用者數去壓（通過加思考時間設定）。

ø  系統的最大tps是一定的（在乙個範圍內），但併發使用者數不一定，可以調整。

ø  建議效能測試的時候，不要設定過長的思考時間，以最壞的情況下對伺服器施壓。

ø  一般情況下，大型系統（業務量大、機器多）做壓力測試，5000個使用者併發就夠了，中小型系統做壓力測試，1000個使用者併發就足夠了。

併發使用者數：是指現實系統中操作業務的使用者，在效能測試工具中，一般稱為虛擬使用者數(virutal

user)

。

併發使用者數一定會對伺服器產生壓力的，

在系統上，對伺服器不產生壓力，

註冊使用者數一般指的是資料庫中存在的使用者數。

tps：transaction per second, 每秒事務數, 是衡量系統效能的乙個非常重要的指標。

tps就是每秒事務數，但是事務是基於虛擬使用者數的，假如1個虛擬使用者在1秒內完成1筆事務，那麼tps明顯就是1；如果

某筆業務響應時間是1ms,那麼1個使用者在1秒內能完成1000筆事務，tps就是1000了；如果某筆業務響應時間是1s,那麼1個使用者在1秒內只能完

成1筆事務，要想達到1000tps，至少需要1000個使用者；因此可以說1個使用者可以產生1000tps，1000個使用者也可以產生1000tps，無

非是看響應時間快慢。

作者最後做了綜述，他認為在效能測試時並不需要用上萬的使用者併發去進行測試，如果只需要保證系統處理業務時間足夠快，幾百個使用者甚至幾十個使用者就可

以達到目的。據他了解，很多專家做過的效能測試專案基本都沒有超過5000使用者併發。因此對於大型系統、業務量非常高、硬體配置足夠多的情況下，5000

使用者併發就足夠了；對於中小型系統，1000使用者併發就足夠了。

效能測試需要一套標準化流程及測試策略，在實際測試時我們還需要考慮其它方面的問題，比如如何模擬成千上萬來自不同地區使用者的訪問場景、如何選用合適的測試軟體。效能測試對一些小的團隊來說並非易事，不過前段時間阿里雲發布了效能測試服務pts，pts可以幫助開發者通過分布式併發壓力測試，模擬指定區域和指定數量的使用者同時訪問，提前預知**承載力。這就是雲計算給我們帶來的便利。

效能測試中TPS和併發使用者數

在做效能測試的時候，很多人都用併發使用者數來衡量系統的效能，覺得系統能支撐的併發使用者數越多，系統的效能就越好 對tps不是非常理解，也根本不知道它們之間的關係，因此非常有必要進行解釋。tps transaction per second,每秒事務數,是衡量系統效能的乙個非常重要的指標，簡單例子 在...

效能測試之 併發使用者數

多使用者，同時 二個因素缺一不可 併發的兩種情況 一種是嚴格意義上的併發，即所有的使用者在同一時刻做同一件事或操作，這種操作一般指做同一型別的業務。比如，所有使用者同一時刻做併發登陸，同一時刻做表單提交。另外一種併發是廣義範圍的併發，這種併發與前一種併發的區別是，儘管多個使用者對系統發出了請求或者進...

效能測試 測試方案 併發使用者數

併發使用者數 同時向伺服器端傳送請求的客戶數。一般根據系統場景和客戶要求來制定具體值。虛擬使用者數和併發使用者數的聯絡 oa系統使用使用者是100個，這個就是系統使用者數。估算併發數的公示 1 計算平均的併發使用者數 c nl t 2 併發使用者數峰值 c c 3根號c 公式 1 中，c是平均的併發...