cpu計算耗時 + cpu等待耗時 + 網路io耗時 + 磁碟io耗時客戶端併發數不等於服務端併發數。雖然服務端同一時刻執行的執行緒數等於cpu個數，但是高效能的服務一般是都會使用了非同步io；遇到io操作就扔給了作業系統執行，cpu接著幹其他的事。所以應用程式同時可以處理多於cpu數目很多的請求。但也不是無限多的。影響併發的系統資源有socket數，頻寬緊張程度，記憶體緊張程度，cpu繁忙程度，磁碟繁忙程度。這些資源共同影響併發數。
這些資源中有些非常充足比如socket數（普通的服務都是設定了600000, 通過ulimit -n檢視），有些就比較匱乏，比如磁碟（具體效率可以去google）。當磁碟遇到瓶頸的時候，socket資源充當了緩衝區。雖然同時能夠接受很多請求，但是真正能做出響應的比較少，造成響應時間增加，這種併發沒有意義。
所以，能保證最低響應時間的併發才是有效併發。
我們在壓力測試過程中，不斷的增加併發數，如果平均響應時間增加，說明併發能力已經到頭了，再加大併發總體效能將要降低。
上面已經談及到，併發數可通過多次實驗來獲得。
下面在來介紹乙個種估算併發資料的方法：
c=n*l/t
c：併發
n：壓測時間段內所有的請求數
l：平均響應時間
t：壓測總時長
這裡注意：l（平均響應時間）≠ t（總時長）/ n（總請求）
從壓測工具談併發、壓力、吞吐量
method for estimating the number of concurrent users
我們在壓測工具製作中，一直存在乙個爭議——吞吐量的計算。
在效能測試中，吞吐量的計算有兩種常見的公式：
公式1： 吞吐量=併發數/平均響應時間
公式2： 吞吐量=請求總數/總時長
公式1、2大家應該都接觸過，雖然看上去不一樣，其實理論上都是ok的。
首先我們可以從c = nl / t 推導：
併發 = 請求總數*平均響應時間 / 總時長
=》併發 / 平均響應時間 = 請求總數 / 總時長
=》公式1 = 公式2
從壓測工具談併發、壓力、吞吐量
heysiege
vegeta
wrkab
QPS和併發數
qps 請求進入的速度 併發數 系統中同時存在的請求數 根據little s law，我們能得到如下的關係式 併發數 qps 耗時 以大學招生為例 大一新生的招收速度是5000人 年，每個學生在大學停留4年，整個大學的人數是20000，於是 下面的qps改為以年為單位 qps 耗時 併發數 5000...
併發使用者數和QPS
關於併發使用者數和qps，自己一直被這兩個概念糾結，閱讀了一下相關資料，總結如下 併發 使用者數和qps兩個概念沒有直接關係，但是如果要說qps時，一定需要指明是多少併發使用者數下的qps，否則豪無意義，因為單使用者數的40qps和20並 發使用者數下的40qps是兩個不同的概念。前者說明該應用可以...
QPS 和併發 如何衡量伺服器端效能
qps 和併發 如何衡量伺服器端效能 和併發相關不得不提的乙個概念就是 qps query per second qps 其實是衡量吞吐量 throughput 的乙個常用指標，就是說伺服器在一秒的時間內處理了多少個請求 我們通常是指 http 請求，顯然數字越大代表伺服器的負荷越高 處理能力越強。...