一、什麼是併發

或許你在網上會得到"絕對併發"和"相對併發"這兩個概念。絕對併發指的是同一時刻的併發數；相對併發指的是一個時間段內發生的事情。

但實際上，我們講併發的時候不需要去區分上面這2個概念。為什麼？

想象中的併發

假設上圖中的這些小人是嚴格按照這個邏輯到達系統的，那顯然，系統的絕對併發使用者數是 4。如果描述 1 秒內的併發使用者數，那就是 16。

實際中的併發

這些使用者會分佈在系統中不同的服務、網路等物件中。這時候"絕對併發"這個概念就難描述了，你說的是哪部分的絕對併發呢？

所以，在講併發的時候，不用有“相對”和“絕對”的概念，這樣可以簡化溝通，也不會出錯。

至於如何描述上面的併發使用者數？可以直接用 TPS

比如說，併發數是 16 TPS，就是指 1 秒內整個系統處理了 16 個事務。

依賴 TPS 來承載的時候，指的都是 Server 端的處理能力，並不是壓力工具上的併發執行緒數。

二、計算併發使用者數

併發使用者數要基於線上使用者數來計算，另外還有一個關鍵引數：併發度。

總共有 32 個使用者進入了系統，但是綠色的使用者並沒有任何動作，那麼顯然，線上使用者數是 32 個，併發使用者數是 16 個，這時的併發度就是 50%。

三、壓力工具中的執行緒數、響應時間和 TPS 的關係

首先，壓力工具中的執行緒或使用者數不是用來描述效能表現的。

"併發使用者數"轉化到"壓力機的併發執行緒數"

可以先做一個基準測試。

比如，這裡有個簡單邏輯：

• JMeter（1 個執行緒） - Nginx - Tomcat - MySQL

此時，單個執行緒下 JMeter 的平均響應時間基本都在 5ms。所以它的 TPS 應該接近 1000ms / 5ms = 200TPS。

現在啟動 10 個執行緒，平均響應時間在 25ms。現在的 TPS 應該接近 (1000ms / 25ms) * 10 = 400TPS。

那麼，就有一個計算公式了：

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

四、總結

梳理線上使用者數、併發使用者數、TPS（這裡假設了一個使用者只對應一個事務）、響應時間之間的關係，需要注意：

• 通常所說的併發都是指服務端的併發，而不是指壓力機上的併發執行緒數，因為服務端的併發才是伺服器的處理能力。
• 效能中常說的併發，是用 TPS 這樣的概念來承載具體數值的。
• 壓力工具中的執行緒數、響應時間和 TPS 之間是有對應關係的。

在效能專案中，要簡化概念，注重實用性。

本文參考：
高樓老師 效能測試實戰30講