高樓老師《性能30講》:?性能測試實戰30講-極客時間?感興趣的同學可以去讀一下，個人感覺寫的非常好

目錄

什么是并發?

在線用戶數、并發用戶數怎么計算

總結

什么是并發?

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

但是，在實際的系統中，用戶通常是這樣分配的：

積分服務的并發，那是 2；庫存服務的并發，那是 5；訂單服務，它自己是 5 個請求正在處理，但同時它又 hold 住了 5 個到庫存服務的鏈接，因為要等著它返回之后，再返回給前端。再細分下去之后，你會發現頭都大了，不知道要怎么描述并發了。

那么如何來描述上面的并發用戶數呢？在這里我建議用 TPS 來承載“并發”這個概念。

并發數是 16TPS，就是 1 秒內整個系統處理了 16 個事務。

在線用戶數、并發用戶數怎么計算

那么新問題又來了，在線用戶數和并發用戶數應該如何算呢？下面我們接著來看示意圖：

????????如上圖所示，總共有 32 個用戶進入了系統，但是綠色的用戶并沒有任何動作，那么顯然，在線用戶數是 32 個，并發用戶數是 16 個，這時的并發度就是 50%。

?但在一個系統中，通常都是下面這個樣子的。

????????為了能 hold 住更多的用戶，我們通常都會把一些數據放到 Redis 這樣的緩存服務器中。所以在線用戶數怎么算呢，如果僅從上面這種簡單的圖來看的話，其實就是緩存服務器能有多大，能 hold 住多少用戶需要的數據。

最多再加上在超時路上的用戶數。如下所示：

????????所以我們要是想知道在線的最大的用戶數是多少，對于一個設計邏輯清晰的系統來說，不用測試就可以知道，直接拿緩存的內存來算就可以了。

????????假設一個用戶進入系統之后，需要用 10k 內存來維護一個用戶的信息，那么 10G 的內存就能 hold 住 1,048,576 個用戶的數據，這就是最大在線用戶數了。在實際的項目中，我們還會將超時放在一起來考慮。

????????但并發用戶數不同，他們需要在系統中執行某個動作。我們要測試的重中之重，就是統計這些正在執行動作的并發用戶數。

????????當我們統計生產環境中的在線用戶數時，并發用戶數也是要同時統計的。這里會涉及到一個概念：并發度。

????????要想計算并發用戶和在線用戶數之間的關系，都需要有并發度。

????????做性能的人都知道，我們有時會接到一個需求，那就是一定要測試出來系統最大在線用戶數是多少。這個需求怎么做呢？

????????很多人都是通過加思考時間（有的壓力工具中叫等待時間，Sleep 時間）來保持用戶與系統之間的 session 不斷，但實際上的并發度非常非常低。

????????這里有一個比較嚴重的理解誤區，那就是壓力工具中的線程或用戶數到底是不是用來描述性能表現的？我們通過一個示意圖來說明：

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

1.?如果有 10000 個在線用戶數，同時并發度是 1%，那顯然并發用戶數就是 100。

2.?如果每個線程的 20TPS，顯然只需要 5 個線程就夠了（請注意，這里說的線程指的是壓力機的線程數）。

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

4.?如果我們有兩個 Server 線程來處理，那么一個線程就是 50TPS，這個很直接吧。

5.?請大家注意，這里我有一個轉換的細節，那就是并發用戶數到壓力機的并發線程數。這一步，我們通常怎么做呢？就是基準測試的第一步。關于這一點，我們在后續的場景中交待。

????????而我們通常說的“并發”這個詞，依賴 TPS 來承載的時候，指的都是 Server 端的處理能力，并不是壓力工具上的并發線程數。在上面的例子中，我們說的并發就是指服務器上 100TPS 的處理能力，而不是指 5 個壓力機的并發線程數。所以，不要在意你用的是什么壓力工具，只要在意你服務端的處理能力就可以了。

現在來看一個實例。這個例子很簡單，就是：

????????我們可以看到，JMeter 的平均響應時間基本都在 5ms，因為只有一個壓力機線程，所以它的 TPS 應該接近 1000ms/5ms=200TPS。從測試結果上來看，也確實是接近的。有人說為什么會少一點？因為這里算的是平均數，并且這個數據是 30s 刷新一次，用 30 秒的時間內完成的事務數除以 30s 得到的，但是如果事務還沒有完成，就不會計算在內了；同時，如果在這段時間內有一兩個時間長的事務，也會拉低 TPS。

那么對于服務端呢，我們來看看服務端線程的工作情況。

可以看到在服務端，我開了 5 個線程，但是服務端并沒有一直干活，只有一個在干活的，其他的都處于空閑狀態。

這是一種很合理的狀態。但是你需要注意的是，這種合理的狀態并不一定是對的性能狀態。

1.?并發用戶數（TPS）是 193.6TPS。如果并發度為 5%，在線用戶數就是 193.6/5%=3872。

2.?響應時間是 5ms。

3.?壓力機并發線程數是 1。這一條，我們通常也不對非專業人士描述，只要性能測試工程師自己知道就可以了。

下面我們換一下場景，在壓力機上啟動 10 個線程。結果如下

平均響應時間在 25ms，我們來計算一處，(1000ms/25ms)*10=400TPS，而最新刷出來的一條是 396.2，是不是非常合理？

下面我們換一下場景，在壓力機上啟動 10 個線程。結果如下：

再回來看看服務端的線程：

同樣是 5 個線程，現在就忙了很多。

并發用戶數（TPS）是 396.2TPS。如果并發度為 5%，在線用戶數就是 396.2/5%=7924。響應時間是 25ms。壓力機并發線程數是 10。

如果要有公式的話，這個計算公式將非常簡單：

TPS=響應時間(單位ms)1000ms??壓力機線程數

????????你也許會說，這個我理解了，服務端有多少個線程，就可以支持多少個壓力機上的并發線程。但是這取決于 TPS 有多少，如果服務端處理的快，那壓力機的并發線程就可以更多一些。

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

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

總結

????????通過示意圖和示例，描述了在線用戶數、并發用戶數、TPS（這里我們假設了一個用戶只對應一個事務）、響應時間之間的關系。有幾點需要強調：

????????1.?通常所說的并發都是指服務端的并發，而不是指壓力機上的并發線程數，因為服務端的并發才是服務器的處理能力。

????????2.?性能中常說的并發，是用 TPS 這樣的概念來承載具體數值的。

????????3.?壓力工具中的線程數、響應時間和 TPS 之間是有對應關系的。