想要購買效能測試工具，如何計算自己需要多少併發使用者？

如果我們需要採購一款 ，我們想要知道，到底需要多少併發使用者數合適？買的太多，需要很高的預算；買的太少，又達不到效果。

目前大多數的軟體架構，大多采用先併發，後排隊的機制。先併發，就是軟體系統有個併發個數，就是同時可以處理多少個請求。例如，一個軟體可以有15個併發，就是能夠滿足同時處理15個請求。如果每個請求處理的時間是200ms，那麼每秒鐘，可以處理的請求個數是：15*（1000/200）=75個。

排隊，就是如果已經有15個請求正在被處理，後來的請求就必須排隊等待。這就有個等待時間的問題。比如，一下來了750個請求，根據每秒處理75個計算，就需要10秒才能處理完成。如果系統實時性很強，要求5秒內必須完成，如果沒有完成，交易就會被取消，那麼我們可以發現，750個請求，其中375個成功了，其他的都失敗了（超時）。

原則上來看，一般軟體的併發個數都不是很高，除非部署了一個大的叢集。如果只考慮tps（每秒透過的交易/請求個數），我們根據每個交易間隔就可以計算出來。比如上面的場景，我們可以要求不能一下來750個，可以在每個請求之間間隔1秒，或者每個交易（包括間隔）為1秒。這樣，在上文鍾，如果tps是75，那麼併發使用者數75個就可以了。

當然，如果我們想要模擬更真實的使用者場景，我們可以根據資料來計算交易的間隔時間（這個部分，可以去搜尋相關的文章）。有了間隔時間，有了對tps的要求，就可以很容易的計算。比如，間隔時間是T，併發個數=tps*T。比如按照上文的例子，如果間隔時間為0.5秒，那麼併發個數為75*0.5=37.5個。

間隔時間，就是作為真實的使用者，平均多長時間會發起一次請求。這個大概用在一段時間內發生的請求總數，除以所使用的時間，就可以計算出來。

下面，我們舉一個實際的例子。

我們期望系統的tps，能夠達到2000，間隔時間為3秒，那麼併發個數（VU）=2000*3=6000併發。這樣做比較真實。

如果擔心預算過高，那麼如果真實的交易處理時間不超過1秒，那麼我們也可以購買VU=2000*1=2000個。這樣我們也可以得到比較接近的效果。

如果交易處理時間，在tps比較高的時候，會變的更長，假設較長是5秒。我們可以讓VU=2000*5=10000即可。

根據上面的說明，我們就可以來估算，大概你需要購買多少個VU了。大概個數跟被測試系統能夠容忍的較大等待時間，以及需要達到的tps個數相關。

推薦閱讀：