什麼是併發
併發數是 16TPS，就是 1 秒內整個系統處理了 16 個事務。
線上使用者數、併發使用者數怎麼計算
如上圖所示，總共有 32 個使用者進入了系統，但是綠色的使用者並沒有任何動作，那麼顯然，線上使用者數是 32 個，併發使用者數是 16 個，這時的併發度就是 50%。
但在一個系統中，通常都是下面這個樣子的。
為了能 hold 住更多的使用者，我們通常都會把一些資料放到 Redis 這樣的快取伺服器中。所以線上使用者數怎麼算呢，如果僅從上面這種簡單的圖來看的話，其實就是快取伺服器能有多大，能 hold 住多少使用者需要的資料。
最多再加上在超時路上的使用者數。如下所示：
所以我們要是想知道線上的最大的使用者數是多少，對於一個設計邏輯清晰的系統來說，不用測試就可以知道，直接拿快取的記憶體來算就可以了。
假設一個使用者進入系統之後，需要用 10k 記憶體來維護一個使用者的資訊，那麼 10G 的記憶體就能 hold 住 1,048,576 個使用者的資料，這就是最大線上使用者數了。在實際的專案中，我們還會將超時放在一起來考慮。
但併發使用者數不同，他們需要在系統中執行某個動作。我們要測試的重中之重，就是統計這些正在執行動作的併發使用者數。
要想計算併發使用者和線上使用者數之間的關係，都需要有併發度。
如果有 10000 個線上使用者數，同時併發度是 1%，那顯然併發使用者數就是 100。
如果每個執行緒的 20TPS，顯然只需要 5 個執行緒就夠了（請注意，這裡說的執行緒指的是壓力機的執行緒數）。
這時對 Server 來說，它處理的就是 100TPS，平均響應時間是 50ms。50ms 就是根據 1000ms/20TPS 得來的（請注意，這裡說的平均響應時間會在一個區間內浮動，但只要 TPS 不變，這個平均響應時間就不會變）。如果我們有兩個 Server 執行緒來處理，那麼一個執行緒就是 50TPS，這個很直接吧。
請大家注意，這裡我有一個轉換的細節，那就是併發使用者數到壓力機的併發執行緒數。
而我們通常說的“併發”這個詞，依賴 TPS 來承載的時候，指的都是 Server 端的處理能力，並不是壓力工具上的併發執行緒數。在上面的例子中，我們說的併發就是指伺服器上 100TPS 的處理能力，而不是指 5 個壓力機的併發執行緒數。
如果要有公式的話，這個計算公式將非常簡單：
TPS=1000ms∗壓力機執行緒數/響應時間(單位ms)
對於壓力工具來說，只要不報錯，我們就關心 TPS 和響應時間就可以了，因為 TPS 反應出來的是和伺服器對應的處理能力，至少壓力執行緒數是多少，並不關鍵。
總結
通過示意圖和示例，我描述了線上使用者數、併發使用者數、TPS（這裡我們假設了一個使用者只對應一個事務）、響應時間之間的關係。有幾點需要強調：
通常所說的併發都是指服務端的併發，而不是指壓力機上的併發執行緒數，因為服務端的併發才是伺服器的處理能力。
效能中常說的併發，是用 TPS 這樣的概念來承載具體數值的。
壓力工具中的執行緒數、響應時間和 TPS 之間是有對應關係的。