4 使用者併發數的計算

什麼是併發？

如何來描述併發使用者數，用 tps 來承載「併發」這個概念就可以了。併發數是 16tps，就是 1 秒內整個系統處理了 16 個事務。這樣描述就夠了，別糾結。

併發使用者數 – 併發度

通過這個圖，我們可以看到乙個簡單的計算邏輯：

如果每個執行緒的 20tps，顯然只需要 5 個執行緒就夠了（請注意，這裡說的執行緒指的是壓力機的執行緒數）。

這時對 server 來說，它處理的就是 100tps，平均響應時間是 50ms。50ms 就是根據 1000ms/20tps 得來的（請注意，這裡說的平均響應時間會在乙個區間內浮動，但只要 tps 不變，這個平均響應時間就不會變）。

如果我們有兩個 server 執行緒來處理，那麼乙個執行緒就是 50tps，這個很直接吧。

請大家注意，這裡我有乙個轉換的細節，那就是併發使用者數到壓力機的併發執行緒數。這一步，我們通常怎麼做呢？就是基準測試的第一步。關於這一點，我們在後續的場景中交待。

而我們通常說的「併發」這個詞，依賴 tps 來承載的時候，指的都是 server 端的處理能力，並不是壓力工具上的併發執行緒數。在上面的例子中，我們說的併發就是指伺服器上 100tps 的處理能力，而不是指 5 個壓力機的併發執行緒數。請你切記這一點，以免溝通障礙。

所以，我一直在強調一點，這是乙個基礎的知識：不要在意你用的是什麼壓力工具，只要在意你服務端的處理能力就可以了。

tps=(1000ms/響應時間(單位ms))∗壓力機執行緒數

對於壓力工具來說，只要不報錯，我們就關心 tps 和響應時間就可以了，因為 tps 反應出來的是和伺服器對應的處理能力，至少壓力執行緒數是多少，並不關鍵。

你也許會說，這個我理解了，服務端有多少個執行緒，就可以支援多少個壓力機上的併發執行緒。但是這取決於 tps 有多少，如果服務端處理的快，那壓力機的併發執行緒就可以更多一些。

這個邏輯看似很合理，但是通常服務端都是有業務邏輯的，既然有業務邏輯，顯然不會比壓力機快。應該說，服務端需要更多的執行緒來處理壓力機執行緒發過來的請求。所以我們用幾台壓力機就可以壓幾十台服務端的效能了。

如果在乙個微服務的系統中，因為每個服務都只做一件事情，拆分得很細，我們要注意整個系統的容量水位，而不是看某乙個服務的能力，這就是拉平整個系統的容量。