性能測試-並發和QPS
響應時間：
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
QPS：每秒請求數，qps是衡量吞吐量指標
我們在壓測工具制作中，一直存在一個爭議——吞吐量的計算。
在性能測試中，吞吐量的計算有兩種常見的公式：
公式1： 吞吐量=並發數/平均響應時間
公式2： 吞吐量=請求總數/總時長
公式1、2大家應該都接觸過，雖然看上去不一樣，其實理論上都是ok的。
首先我們可以從C = nL / T 推導：
並發 = 請求總數*平均響應時間 / 總時長
=》並發 / 平均響應時間 = 請求總數 / 總時長
=》公式1 = 公式2
摘自：
從壓測工具談並發、壓力、吞吐量
性能測試工具
附上一些性能測試工具，排名不分先后，大家喜歡哪個用哪個。