在做效能測試的時候，很多人都用併發使用者數來衡量系統的效能，覺得系統能支撐的併發使用者數越多，系統的效能就越好；對tps不是非常理解，也根本不知道它們之間的關係，因此非常有必要進行解釋。
tps是每秒事務數，但是事務是要靠虛擬使用者做出來的，假如1個虛擬使用者在1秒 內完成1筆事務，那麼tps明顯就是1；如果某筆業務響應時間是1ms,那麼1個使用者在1秒內能完成1000筆事務，tps就是1000了；如果某筆業務 響應時間是1s,那麼1個使用者在1秒內只能完成1筆事務，要想達到1000tps，至少需要1000個使用者；因此可以說1個使用者可以產生 1000tps，1000個使用者也可以產生1000tps，無非是看響應時間快慢。
（1）併發使用者數(vu)獲取
（2）tps獲取
舊系統：對於已經上線的系統，可以選取高峰時刻，在5分鐘或10分鐘內，獲取系統每筆交易的業務量和總業務量，按照單位時間內完成的筆數計算出tps，即業務筆數/單位時間（5*60或10*60）
針對伺服器端的效能，以tps為主來衡量系統的效能，併發使用者數為輔來衡量系統的效能，如果必須要用併發使用者數來衡量的話，需要乙個前提，那就是交 易在多長時間內完成（系統響應時間），因為在系統負載不高的情況下，將思考時間(思考時間的值等於交易響應時間)加到指令碼中，併發使用者數基本可以增加一倍，因此用併發使用者 數來衡量系統的效能沒太大的意義。
響應時間= 網路傳輸時間 + 應用伺服器處理時間 + 資料庫伺服器處理時間
通過大量效能測試我們發現不需要用上萬的使用者併發去進行測試，只要系統處理業務時間足夠快，幾百個使用者甚至幾十個使用者就可以達到目的。另外諮詢很多專家做過的效能測試專案，基本都沒有超過5000使用者併發。
因此對於大型系統、業務量非常高、硬體配置足夠多的情況下，5000使用者併發就足夠了；對於中小型系統，1000使用者併發就足夠了。
做效能測試需要一套標準化流程及測試策略，併發使用者數只是指標考慮的乙個，在做負載測試的時候，一般都是按照梯度施壓的方式去加使用者數，而不是在沒 有預估的情況下，一次加幾萬個使用者，，交易失敗率非常高，響應時間非常長，已經超過了使用者忍受範圍內，這樣做沒有多大的意義，這就好比「有多少錢可以幹多少事」一樣，需要選擇相關的策略。
效能測試知多少 併發使用者
在做效能測試 的時候，我們常常聽到併發使用者 響應時間 吞吐量專業術語，也許大家都理解，這裡有乙個理解的層次與深度概念。最近有看斷念 軟體效能詳解與案例分析 一書，看了他的講解，原來我對這些術語的理解還是比較膚淺，其實，這裡也主要受制於自己的知識面。所以，再拿出來與大家重溫一下。ps 按照慣例先上個...
效能測試之 併發使用者數
多使用者，同時 二個因素缺一不可 併發的兩種情況 一種是嚴格意義上的併發，即所有的使用者在同一時刻做同一件事或操作，這種操作一般指做同一型別的業務。比如，所有使用者同一時刻做併發登陸，同一時刻做表單提交。另外一種併發是廣義範圍的併發，這種併發與前一種併發的區別是，儘管多個使用者對系統發出了請求或者進...
效能測試 測試方案 併發使用者數
併發使用者數 同時向伺服器端傳送請求的客戶數。一般根據系統場景和客戶要求來制定具體值。虛擬使用者數和併發使用者數的聯絡 oa系統使用使用者是100個，這個就是系統使用者數。估算併發數的公示 1 計算平均的併發使用者數 c nl t 2 併發使用者數峰值 c c 3根號c 公式 1 中，c是平均的併發...