一、什么是並發
或許你在網上會得到"絕對並發"和"相對並發"這兩個概念。絕對並發指的是同一時刻的並發數；相對並發指的是一個時間段內發生的事情。
但實際上，我們講並發的時候不需要去區分上面這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講