什么是并發(fā)
我們假設(shè)上圖中的這些小人是嚴(yán)格按照這個(gè)邏輯到達(dá)系統(tǒng)的，那顯然，系統(tǒng)的絕對并發(fā)用戶數(shù)是 4。如果描述 1 秒內(nèi)的并發(fā)用戶數(shù)，那就是 16。是不是顯而易見？
但是，在實(shí)際的系統(tǒng)中，用戶通常是這樣分配的：
也就是說，這些用戶會分布在系統(tǒng)中不同的服務(wù)、網(wǎng)絡(luò)等對象中。這時(shí)候”絕對并發(fā)“這個(gè)概念就難描述了，你說的是哪部分的絕對并發(fā)呢？
要說積分服務(wù)，那是 2；要說庫存服務(wù)，那是 5；要說訂單服務(wù)，它自己是 5 個(gè)請求正在處理，但同時(shí)它又 hold 住了 5 個(gè)到庫存服務(wù)的鏈接，因?yàn)橐戎祷刂螅俜祷亟o前端。所以將絕對并發(fā)細(xì)分下去之后，你會發(fā)現(xiàn)頭都大了，不知道要描述什么了。
有人說，我們可以通過 CPU 啊，I/O 啊，或者內(nèi)存來描述絕對并發(fā)，來看 CPU 在同一時(shí)刻處理的任務(wù)數(shù)。如果是這樣的話，絕對并發(fā)還用算嗎？那肯定是 CPU 的個(gè)數(shù)呀。有人說 CPU 1ns 就可以處理好多個(gè)任務(wù)了，這里的 1ns 也是時(shí)間段呀。要說絕對的某個(gè)時(shí)刻，任務(wù)數(shù)肯定不會大于 CPU 物理個(gè)數(shù)。
所以“絕對并發(fā)”這個(gè)概念，不管是用來描述硬件細(xì)化的層面，還是用來描述業(yè)務(wù)邏輯的層面，都是沒什么意義的。
我們只要描述并發(fā)就好了，不用有“相對”和“絕對”的概念，這樣可以簡化溝通，也不會出錯。
那么如何來描述上面的并發(fā)用戶數(shù)呢？在這里我建議用 TPS 來承載“并發(fā)”這個(gè)概念。
并發(fā)數(shù)是 16TPS，就是 1 秒內(nèi)整個(gè)系統(tǒng)處理了 16 個(gè)事務(wù)。
這樣描述就夠了，別糾結(jié)。
在線用戶數(shù)、并發(fā)用戶數(shù)怎么計(jì)算
那么新問題又來了，在線用戶數(shù)和并發(fā)用戶數(shù)應(yīng)該如何算呢？下面我們接著來看示意圖：
如上圖所示，總共有 32 個(gè)用戶進(jìn)入了系統(tǒng)，但是綠色的用戶并沒有任何動作，那么顯然，在線用戶數(shù)是 32 個(gè)，并發(fā)用戶數(shù)是 16 個(gè)，這時(shí)的并發(fā)度就是 50%。
但在一個(gè)系統(tǒng)中，通常都是下面這個(gè)樣子的。
為了能 hold 住更多的用戶，我們通常都會把一些數(shù)據(jù)放到 Redis 這樣的緩存服務(wù)器中。所以在線用戶數(shù)怎么算呢，如果僅從上面這種簡單的圖來看的話，其實(shí)就是緩存服務(wù)器能有多大，能 hold 住多少用戶需要的數(shù)據(jù)。
最多再加上在超時(shí)路上的用戶數(shù)。如下所示：
所以我們要是想知道在線的最大的用戶數(shù)是多少，對于一個(gè)設(shè)計(jì)邏輯清晰的系統(tǒng)來說，不用測試就可以知道，直接拿緩存的內(nèi)存來算就可以了。
假設(shè)一個(gè)用戶進(jìn)入系統(tǒng)之后，需要用 10k 內(nèi)存來維護(hù)一個(gè)用戶的信息，那么 10G 的內(nèi)存就能 hold 住 1,048,576 個(gè)用戶的數(shù)據(jù)，這就是最大在線用戶數(shù)了。在實(shí)際的項(xiàng)目中，我們還會將超時(shí)放在一起來考慮。
但并發(fā)用戶數(shù)不同，他們需要在系統(tǒng)中執(zhí)行某個(gè)動作。我們要測試的重中之重，就是統(tǒng)計(jì)這些正在執(zhí)行動作的并發(fā)用戶數(shù)。
當(dāng)我們統(tǒng)計(jì)生產(chǎn)環(huán)境中的在線用戶數(shù)時(shí)，并發(fā)用戶數(shù)也是要同時(shí)統(tǒng)計(jì)的。這里會涉及到一個(gè)概念：并發(fā)度。
要想計(jì)算并發(fā)用戶和在線用戶數(shù)之間的關(guān)系，都需要有并發(fā)度。
做性能的人都知道，我們有時(shí)會接到一個(gè)需求，那就是一定要測試出來系統(tǒng)最大在線用戶數(shù)是多少。這個(gè)需求怎么做呢？
很多人都是通過加思考時(shí)間（有的壓力工具中叫等待時(shí)間，Sleep 時(shí)間）來保持用戶與系統(tǒng)之間的 session 不斷，但實(shí)際上的并發(fā)度非常非常低。
我曾經(jīng)看到一個(gè)小伙，在一臺 4C8G 的筆記本上用 LoadRunner 跑了 1 萬個(gè)用戶，里面的 error 瘋狂上漲，當(dāng)然正常的事務(wù)也有。我問他，你這個(gè)場景有什么意義，這么多錯？他說，老板要一個(gè)最大在線用戶數(shù)。我說你這些都錯了呀。他說，沒事，我要的是 Running User 能達(dá)到最大就行，給老板交差。我只能默默地離開了。
這里有一個(gè)比較嚴(yán)重的理解誤區(qū)，那就是壓力工具中的線程或用戶數(shù)到底是不是用來描述性能表現(xiàn)的？我們通過一個(gè)示意圖來說明：
通過這個(gè)圖，我們可以看到一個(gè)簡單的計(jì)算邏輯：
- 如果有 10000 個(gè)在線用戶數(shù)，同時(shí)并發(fā)度是 1%，那顯然并發(fā)用戶數(shù)就是 100。
- 如果每個(gè)線程的 20TPS，顯然只需要 5 個(gè)線程就夠了（請注意，這里說的線程指的是壓力機(jī)的線程數(shù)）。
- 這時(shí)對 Server 來說，它處理的就是 100TPS，平均響應(yīng)時(shí)間是 50ms。50ms 就是根據(jù) 1000ms/20TPS 得來的（請注意，這里說的平均響應(yīng)時(shí)間會在一個(gè)區(qū)間內(nèi)浮動，但只要 TPS 不變，這個(gè)平均響應(yīng)時(shí)間就不會變）。
- 如果我們有兩個(gè) Server 線程來處理，那么一個(gè)線程就是 50TPS，這個(gè)很直接吧。
- 請大家注意，這里我有一個(gè)轉(zhuǎn)換的細(xì)節(jié)，那就是并發(fā)用戶數(shù)到壓力機(jī)的并發(fā)線程數(shù)。這一步，我們通常怎么做呢？就是基準(zhǔn)測試的第一步。關(guān)于這一點(diǎn)，我們在后續(xù)的場景中交待。
而我們通常說的“并發(fā)”這個(gè)詞，依賴 TPS 來承載的時(shí)候，指的都是 Server 端的處理能力，并不是壓力工具上的并發(fā)線程數(shù)。在上面的例子中，我們說的并發(fā)就是指服務(wù)器上 100TPS 的處理能力，而不是指 5 個(gè)壓力機(jī)的并發(fā)線程數(shù)。請你切記這一點(diǎn)，以免溝通障礙。
所以，我一直在強(qiáng)調(diào)一點(diǎn)，這是一個(gè)基礎(chǔ)的知識：不要在意你用的是什么壓力工具，只要在意你服務(wù)端的處理能力就可以了。
示例
上面說了這么多，我們現(xiàn)在來看一個(gè)實(shí)例。這個(gè)例子很簡單，就是：
JMeter（1 個(gè)線程） - Nginx - Tomcat - MySQL
通過上面的邏輯，我們先來看看 JMeter 的處理情況：
summary + 5922 in 00:00:30 = 197.4/s Avg: 4 Min: 0 Max: 26 Err: 0 (0.00%) Active: 1 Started: 1 Finished: 0
summary = 35463 in 00:03:05 = 192.0/s Avg: 5 Min: 0 Max: 147 Err: 0 (0.00%)
summary + 5922 in 00:00:30 = 197.5/s Avg: 4 Min: 0 Max: 24 Err: 0 (0.00%) Active: 1 Started: 1 Finished: 0
summary = 41385 in 00:03:35 = 192.8/s Avg: 5 Min: 0 Max: 147 Err: 0 (0.00%)
summary + 5808 in 00:00:30 = 193.6/s Avg: 5 Min: 0 Max: 25 Err: 0 (0.00%) Active: 1 Started: 1 Finished: 0
summary = 47193 in 00:04:05 = 192.9/s Avg: 5 Min: 0 Max: 147 Err: 0 (0.00%)
我們可以看到，JMeter 的平均響應(yīng)時(shí)間基本都在 5ms，因?yàn)橹挥幸粋€(gè)壓力機(jī)線程，所以它的 TPS 應(yīng)該接近 1000ms/5ms=200TPS。從測試結(jié)果上來看，也確實(shí)是接近的。有人說為什么會少一點(diǎn)？因?yàn)檫@里算的是平均數(shù)，并且這個(gè)數(shù)據(jù)是 30s 刷新一次，用 30 秒的時(shí)間內(nèi)完成的事務(wù)數(shù)除以 30s 得到的，但是如果事務(wù)還沒有完成，就不會計(jì)算在內(nèi)了；同時(shí)，如果在這段時(shí)間內(nèi)有一兩個(gè)時(shí)間長的事務(wù)，也會拉低 TPS。
那么對于服務(wù)端呢，我們來看看服務(wù)端線程的工作情況。
可以看到在服務(wù)端，我開了 5 個(gè)線程，但是服務(wù)端并沒有一直干活，只有一個(gè)在干活的，其他的都處于空閑狀態(tài)。
這是一種很合理的狀態(tài)。但是你需要注意的是，這種合理的狀態(tài)并不一定是對的性能狀態(tài)。
- 并發(fā)用戶數(shù)（TPS）是 193.6TPS。如果并發(fā)度為 5%，在線用戶數(shù)就是 193.6/5%=3872。
- 響應(yīng)時(shí)間是 5ms。
- 壓力機(jī)并發(fā)線程數(shù)是 1。這一條，我們通常也不對非專業(yè)人士描述，只要性能測試工程師自己知道就可以了。
下面我們換一下場景，在壓力機(jī)上啟動 10 個(gè)線程。結(jié)果如下：
summary + 11742 in 00:00:30 = 391.3/s Avg: 25 Min: 0 Max: 335 Err: 0 (0.00%) Active: 10 Started: 10 Finished: 0
summary = 55761 in 00:02:24 = 386.6/s Avg: 25 Min: 0 Max: 346 Err: 0 (0.00%)
summary + 11924 in 00:00:30 = 397.5/s Avg: 25 Min: 0 Max: 80 Err: 0 (0.00%) Active: 10 Started: 10 Finished: 0
summary = 67685 in 00:02:54 = 388.5/s Avg: 25 Min: 0 Max: 346 Err: 0 (0.00%)
summary + 11884 in 00:00:30 = 396.2/s Avg: 25 Min: 0 Max: 240 Err: 0 (0.00%) Active: 10 Started: 10 Finished: 0
summary = 79569 in 00:03:24 = 389.6/s Avg: 25 Min: 0 Max: 346 Err: 0 (0.00%)
平均響應(yīng)時(shí)間在 25ms，我們來計(jì)算一處，(1000ms/25ms)*10=400TPS，而最新刷出來的一條是 396.2，是不是非常合理？
同樣是 5 個(gè)線程，現(xiàn)在就忙了很多。
- 并發(fā)用戶數(shù)（TPS）是 396.2TPS。
- 如果并發(fā)度為 5%，在線用戶數(shù)就是 396.2/5%=7924。響應(yīng)時(shí)間是 25ms。
- 壓力機(jī)并發(fā)線程數(shù)是 10。這一條，我們通常也不對非專業(yè)人士描述，只要性能測試工程師自己知道就可以了。
如果要有公式的話，這個(gè)計(jì)算公式將非常簡單：
對于壓力工具來說，只要不報(bào)錯，我們就關(guān)心 TPS 和響應(yīng)時(shí)間就可以了，因?yàn)?TPS 反應(yīng)出來的是和服務(wù)器對應(yīng)的處理能力，至少壓力線程數(shù)是多少，并不關(guān)鍵。我想這時(shí)會有人能想起來 JMeter 的 BIO 和 AIO 之爭吧。
你也許會說，這個(gè)我理解了，服務(wù)端有多少個(gè)線程，就可以支持多少個(gè)壓力機(jī)上的并發(fā)線程。但是這取決于 TPS 有多少，如果服務(wù)端處理的快，那壓力機(jī)的并發(fā)線程就可以更多一些。
這個(gè)邏輯看似很合理，但是通常服務(wù)端都是有業(yè)務(wù)邏輯的，既然有業(yè)務(wù)邏輯，顯然不會比壓力機(jī)快。
應(yīng)該說，服務(wù)端需要更多的線程來處理壓力機(jī)線程發(fā)過來的請求。所以我們用幾臺壓力機(jī)就可以壓幾十臺服務(wù)端的性能了。
如果在一個(gè)微服務(wù)的系統(tǒng)中，因?yàn)槊總€(gè)服務(wù)都只做一件事情，拆分得很細(xì)，我們要注意整個(gè)系統(tǒng)的容量水位，而不是看某一個(gè)服務(wù)的能力，這就是拉平整個(gè)系統(tǒng)的容量。
我曾經(jīng)看一個(gè)人做壓力的時(shí)候，壓力工具中要使用 4000 個(gè)線程，結(jié)果給服務(wù)端的 Tomcat 上也配置了 4000 個(gè)線程，結(jié)果 Tomcat 一啟動，稍微有點(diǎn)訪問，CS 就特別高，結(jié)果導(dǎo)致請求沒處理多少，自己倒浪費(fèi)了不少 CPU。
總結(jié)
通過示意圖和示例，我描述了在線用戶數(shù)、并發(fā)用戶數(shù)、TPS（這里我們假設(shè)了一個(gè)用戶只對應(yīng)一個(gè)事務(wù)）、響應(yīng)時(shí)間之間的關(guān)系。有幾點(diǎn)需要強(qiáng)調(diào)：
- 通常所說的并發(fā)都是指服務(wù)端的并發(fā)，而不是指壓力機(jī)上的并發(fā)線程數(shù)，因?yàn)榉?wù)端的并發(fā)才是服務(wù)器的處理能力。
- 性能中常說的并發(fā)，是用 TPS 這樣的概念來承載具體數(shù)值的。
- 壓力工具中的線程數(shù)、響應(yīng)時(shí)間和 TPS 之間是有對應(yīng)關(guān)系的。
