效能測試中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)更能讓客戶接受。

方向對比項loadrunnerpts備註

基礎設施

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

需要不需要

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

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

需要不需要

基礎設施軟硬體由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是平均的併發...