衡量網站性能時，並發數與吞吐量為何要分別考量？

01-09

私以為並發數與吞吐量是正相關的，並發數高，吞吐量必然高，何必多此一舉？

我覺得，並發數更多是看同一時刻能同時處理的數量。（比如雙十一時峰值很大）

吞吐量是一段時間內能處理的數量。（平時主要看這個）

並發數、吞吐量的概念最初用來衡量網路設備的性能，後來推廣到伺服器及業務上評估系統的整體性能。

一、網路設備的並發數、吞吐量

並發數（Concurrency）：

也叫並發連接數，指網路設備所能處理的最大會話數量。這裡的會話數是指請求-&>響應一次會話。

吞吐量（Throughput）：

用戶請求是由一個個數據包組成，網路設備（防火牆/路由器/交換機）對每個數據包的處理要耗費資源。吞吐量是指在不丟包的情況下單位時間內通過網路設備的數據包數量。

網路層面並發數和吞吐量的關係：

並發數x包長度=吞吐量

參考：吞吐與並發關係

可以看出，在網路層面考察吞吐量，除了並發數，還要考慮請求包的大小（長度）。用於度量網路設備時候，可以用byte/秒。

二、伺服器及業務上的並發數、吞吐量

用於指網站性能/伺服器性能時候：

並發數：系統同時處理的請求數（分為查詢類請求數、事務類請求數）。

吞吐量：系統在單位時間內處理請求的數量。只不過是一個很寬泛的術語，大家經常指的吞吐量的單位可能是：TPS/QPS、頁面數/秒、人數/天、處理業務數/小時等等。

幾個相關的概念：TPS、QPS、RPS

TPS：Transactions Per Second（每秒事務處理數），指伺服器每秒處理的事務次數。一般用於評估資料庫、交易系統的基準性能。

QPS：Queries Per Second（查詢量/秒），是伺服器每秒能夠處理的查詢次數，例如域名伺服器、Mysql查詢性能。

RPS：Request Per Second（請求數/秒）

RPS（Request Per Second）和QPS可以認為是一回事。

RT：Response Time（響應時間）：客戶端發一個請求開始計時，到客戶端接收到從伺服器端返回的響應結果結束所經歷的時間，響應時間由請求發送時間、網路傳輸時間和伺服器處理時間三部分組成。也叫Think Time。

並發數與TPS/QPS的關係：

QPS（TPS）= 並發數/平均響應時間

這裡的並發數如果為事務處理請求數，則為TPS，如果為查詢請求數，則為QPS。

參考：http://www.ha97.com/5095.html

回到題主的問題：並發數高，吞吐量是否必然高？

個人覺得不一定。

如果談的是網路設備，參照：並發數x包長度=吞吐量，吞吐量依賴於並發數和包長度。

如果談的是伺服器及完整整體性能，需要明確吞吐量的度量指標，假定以吞吐量以QPS作為度量指標，如果並發數高，但平均響應時間上不去，則QPS並不一定高。

為什麼要分別考量？就是個rt問題。

一條馬路，2個車道，並發最高就只能為2。但是吞吐量呢，表示一段時間內通過的車輛數。

如果2個車道都被堵住了，rt很大，那麼並發為2，吞吐量為0；如果沒有堵車，通過很快，rt很低，吞吐量就很高。

所以，還是看rt。

假設並發為10，單個任務平均延遲為0.2秒，則每秒吞吐最大值就是50；

假設並發為10，單個任務平均延遲為1秒，則每秒最大吞吐只有10；

假設並發為1，單個任務平均延遲為0.1秒，則每秒最大吞吐還是10；

吞吐量是由並發與延遲共同決定的，整個服務對客戶的效率最終取決於吞吐量，而不是並發數。就像銀行櫃檯可以同時開很多窗口，但如果每個窗口都做繁瑣的開戶操作，那麼對等待的人來說，效率也是不高的。

俺不知道你說的這個並發數是什麼... 所以我就先將你的並發數理解成TPS好了

假設你有一個訂單系統 TPS在3~4k 我們就理解成一分鐘能處理180k的請求

但是這些請求不是很平均的每秒給你發過來的比如"秒殺" 是在一瞬間發生的吞吐量在這裡就有意義了

如果說你的吞吐量為0 沒有任何緩衝機制那麼超過你正常的負載程序就會崩潰

如果你的吞吐量為200k 在處理性能沒有變化的情況下程序不會崩潰並且能在一分鐘內把這些請求處理掉

你應該對並發量理解有誤。吞吐量是計算出來的，而則並發是源指標，如果你的系統存在某項瓶頸（而實際上一定有），達到資源瓶頸時，你的事務處理時間會隨著並發數增大而變長，最終直觀表現就是吞吐量到達天花板，甚至下降。我們不可能的無限提高瓶頸，所以要在這三個相關指標都維持在可接受範圍內，做出取捨。我覺得問出這個問題，應該是片面認為事務處理時間或者乾脆說RT是基本不變的，但這個指標我實際工作中的感覺才是最不穩定的，因為一切皆有瓶頸

定性的來說，在並發量較低的情況下，吞吐量與並發量成正比，此時後台處理能力充足。

當並發量到達一定的數量後，伺服器處理能力不足（線程切換），吞吐量反而降低。

下面是我的一個案例

``` ./wrk -t12 -c400 -d30s --latency http://some-ip/workflow/api/v1/aaa?token=2031930f9bb649dd808e9c7d9bc4109e Running 30s test @ http://some-ip/workflow/api/v1/aaa?token=2031930f9bb649dd808e9c7d9bc4109e 12 threads and 400 connections Thread Stats Avg Stdev Max +/- Stdev Latency 489.90ms 231.94ms 1.12s 59.59% Req/Sec 49.22 25.22 166.00 65.69% Latency Distribution 50% 486.96ms 75% 680.42ms 90% 804.78ms 99% 938.91ms 14519 requests in 30.08s, 4.22MB read Socket errors: connect 155, read 0, write 0, timeout 0 Requests/sec: 482.70 Transfer/sec: 143.74KB ``` 並發數 = Requests/sec * Latency(Avg) = 482.70 * 489.90/1000 = 188.66


```

./wrk -t12 -c500 -d30s --latency http://some-ip/workflow/api/v1/aaa?token=2031930f9bb649dd808e9c7d9bc4109e

Running 30s test @ http://some-ip/workflow/api/v1/aaa?token=2031930f9bb649dd808e9c7d9bc4109e

  12 threads and 500 connections

  Thread Stats   Avg      Stdev     Max   +/- Stdev

    Latency   486.49ms  224.32ms   1.32s    62.23%

    Req/Sec    51.79     35.83   181.00     65.56%

  Latency Distribution

     50%  476.80ms

     75%  663.52ms

     90%  793.21ms

     99%  961.47ms

  14495 requests in 30.10s, 4.22MB read

  Socket errors: connect 251, read 0, write 0, timeout 0

Requests/sec:    481.53

Transfer/sec:    143.40KB

``` 並發數 = Requests/sec * Latency(Avg) = 481.53 * 486.49/1000 = 234

並發數提高了，但是Requests/sec 反而降低了一些。

上面都是什麼鬼？題主的認知都是錯誤的，在沒達到系統瓶頸時，吞吐量和並發數是正相關的。到達瓶頸後，吞吐量和並發數沒有正相關關係。