近日，hitest在其技術部落格上發表了一篇題為《併發使用者數與tps之間的關係》的文章，文章對tps和併發使用者數做了詳細的解釋，並針對性能測試中系統效能的衡量維度和測試策略給出了自己的建議。hitest是阿里巴巴技術質量部提供的一款web&移動應用安全測試saas化服務平台，旨在幫助開發者簡單快捷地進行安全測試。
在文中，作者首先對併發使用者數和tps做了解釋：
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可以幫助開發者通過分布式併發壓力測試，模擬指定區域和指定數量的使用者同時訪問，提前預知**承載力。這就是雲計算給我們帶來的便利。
效能測試中如何確定併發使用者數
在文中，作者首先對併發使用者數和tps做了解釋 併發使用者數 是指現實系統中操作業務的使用者，在效能測試工具中，一般稱為虛擬使用者數 virutal user 併發使用者數和註冊使用者數 使用者數的概念不同，併發使用者數一定會對伺服器產生壓力的，而 使用者數只是 掛 在系統上，對伺服器不產生壓力，註...
效能測試中如何確定併發使用者數
在文中，作者首先對併發使用者數和tps做了解釋 併發使用者數 是指現實系統中操作業務的使用者，在效能測試工具中，一般稱為虛擬使用者數 virutal user 併發使用者數和註冊使用者數 使用者數的概念不同，併發使用者數一定會對伺服器產生壓力的，而 使用者數只是 掛 在系統上，對伺服器不產生壓力，註...
效能測試如何計算併發使用者數
在實際的 效能測試 工作 中，測試人員常常會關心到併發使用者數，也就是從業務角度關注究竟應該設定多少個併發數比較合理，以下是乙個估算併發使用者數的方法 1 計算平均的併發使用者數 c nl t 2 併發使用者數峰值 c c 3根號c 公式 1 中，c是平均的併發使用者數 n是login sessio...