在學習極客時間性能測試30講中，有不錯的描述，總結如下：
這裡有一個比較嚴重的了解誤區，那就是壓力工具中的線程或使用者數到底是不是用來描述性
能表現的？我們通過一個示意圖來說明：
通過這個圖，我們可以看到一個簡單的計算邏輯：
1. 如果有 10000 個線上使用者數，同時并發度是 1%，那顯然并發使用者數就是 100。
2. 如果每個線程的 20TPS，顯然隻需要 5 個線程就夠了（請注意，這裡說的線程指的是壓
力機的線程數）。
3. 這時對 Server 來說，它處理的就是 100TPS，平均響應時間是 50ms。50ms 就是根據
1000ms/20TPS 得來的（請注意，這裡說的平均響應時間會在一個區間内浮動，但隻要
TPS 不變，這個平均響應時間就不會變）。
4. 如果我們有兩個 Server 線程來處理，那麼一個線程就是 50TPS，這個很直接吧。
5. 請大家注意，這裡我有一個轉換的細節，那就是
并發使用者數到壓力機的并發線程數
。這
一步，我們通常怎麼做呢？就是基準測試的第一步。關于這一點，我們在後續的場景中
交待。
而我們通常說的“并發”這個詞，依賴 TPS 來承載的時候，指的都是 Server 端的處理能
力，并不是壓力工具上的并發線程數。在上面的例子中，我們說的并發就是指伺服器上
100TPS 的處理能力，而不是指 5 個壓力機的并發線程數。
請你切記這一點，以免溝通障
礙
。
在我帶過的所有項目中，這都是一個溝通的前提。
是以，我一直在強調一點，這是一個基礎的知識：
不要在意你用的是什麼壓力工具，隻要在
意你服務端的處理能力就可以了
。
示例
上面說了這麼多，我們現在來看一個執行個體。這個例子很簡單，就是：
JMeter（1 個線程） - Nginx - Tomcat - MySQL
通過上面的邏輯，我們先來看看 JMeter 的處理情況：
複制代碼
1
summary +
5922
in
00
:
00
:
30
=
197.4
/s Avg:
4
Min:
Max:
26
Err:
2
summary =
35463
in
00
:
03
:
05
=
192.0
/s Avg:
5
Min:
Max:
147
Err:
3
summary +
5922
in
00
:
00
:
30
=
197.5
/s Avg:
4
Min:
Max:
24
Err:
4
summary =
41385
in
00
:
03
:
35
=
192.8
/s Avg:
5
Min:
Max:
147
Err:
5
summary +
5808
in
00
:
00
:
30
=
193.6
/s Avg:
5
Min:
Max:
25
Err:
6
summary =
47193
in
00
:
04
:
05
=
192.9
/s Avg:
5
Min:
Max:
147
Err:
我們可以看到，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 個線程。結果如下：
複制代碼
1
summary +
11742
in
00
:
00
:
30
=
391.3
/s Avg:
25
Min:
Max:
335
Err:
2
summary =
55761
in
00
:
02
:
24
=
386.6
/s Avg:
25
Min:
Max:
346
Err:
3
summary +
11924
in
00
:
00
:
30
=
397.5
/s Avg:
25
Min:
Max:
80
Err:
4
summary =
67685
in
00
:
02
:
54
=
388.5
/s Avg:
25
Min:
Max:
346
Err:
5
summary +
11884
in
00
:
00
:
30
=
396.2
/s Avg:
25
Min:
Max:
240
Err:
6
summary =
79569
in
00
:
03
:
24
=
389.6
/s Avg:
25
Min:
Max:
346
Err:
平均響應時間在 25ms，我們來計算一處，(1000ms/25ms)*10=400TPS，而最新刷出來
的一條是 396.2，是不是非常合理？
再回來看看服務端的線程：
同樣是 5 個線程，現在就忙了很多。
1. 并發使用者數（TPS）是 396.2TPS。如果并發度為 5%，線上使用者數就是
396.2/5%=7924。
2. 響應時間是 25ms。如果要有公式的話，這個計算公式将非常簡單：
我不打算再将此公式複雜化，是以就不再用字母替代了。
這就是我經常提到的， 對于壓力工具來說，隻要不報錯，我們就關心 TPS 和響應時間就可
以了，因為 TPS 反應出來的是和伺服器對應的處理能力，至少壓力線程數是多少，并不關
鍵
。我想這時會有人能想起來 JMeter 的 BIO 和 AIO 之争吧。
你也許會說，這個我了解了，服務端有多少個線程，就可以支援多少個壓力機上的并發線
程。但是這取決于 TPS 有多少，如果服務端處理的快，那壓力機的并發線程就可以更多一
些。
這個邏輯看似很合理，但是通常服務端都是有業務邏輯的，既然有業務邏輯，顯然不會比壓
力機快。
應該說，服務端需要更多的線程來處理壓力機線程發過來的請求。是以我們用幾台壓力機就
可以壓幾十台服務端的性能了。
如果在一個微服務的系統中，因為每個服務都隻做一件事情，拆分得很細，我們要注意整個
系統的容量水位，而不是看某一個服務的能力，這就是拉平整個系統的容量。
我曾經看一個人做壓力的時候，壓力工具中要使用 4000 個線程，結果給服務端的 Tomcat
上也配置了 4000 個線程，結果 Tomcat 一啟動，稍微有點通路，CS 就特别高，結果導緻
![淺談---測試Native Windows Command與Native PowerShell Command哪個效率高[圖]](data:image/gif;base64,R0lGODlhAQABAIAAAP///wAAACwAAAAAAQABAAACAkQBADs=)