系統吞吐量、QPS(TPS)、併發數等概念
1. 概念
1.1. 系統吞吐量 1.2. QPS(TPS) 1.3. 併發數 1.4. 響應時間 1.5. 關係
2. 系統吞吐量評估
1.系統吞吐量
一個系統的吞度量（承壓能力）與request對CPU的消耗、外部介面、IO等等緊密關聯。單個reqeust 對CPU消耗越高，外部系統介面、IO影響速度越慢，系統吞吐能力越低，反之越高。 系統吞吐量幾個重要引數：QPS（TPS）、併發數、響應時間 QPS（TPS）：每秒鐘request/事務 數量 併發數： 系統同時處理的request/事務數 響應時間： 一般取平均響應時間
(很多人經常會把併發數和TPS理解混淆）
理解了上面三個要素的意義之後，就能推算出它們之間的關係：
QPS（TPS）= 併發數/平均響應時間 或者 併發數 = QPS*平均響應時間
假設壓力測試出的QPS(TPS)為100，在併發數等要素不超標的情況下，系統的日吞吐量大致:100 * 10 * 3600=360萬(相當於按最高TPS訪問10個小時)。 一個典型的上班簽到系統，早上8點上班，7點半到8點的30分鐘的時間裡使用者會登入簽到系統進行簽到。公司員工為1000人，平均每個員上登入簽到系統的時長為5分鐘。可以用下面的方法計算。
QPS = 1000/(30 * 60)事務/秒
平均響應時間為 = 5 * 60秒
併發數= QPS*平均響應時間=1000/(30 * 60) *(5 * 60)=166.7。
3.QPS
每秒鐘處理完請求的次數；注意這裡是處理完。具體是指發出請求到伺服器處理完成功返回結果。可以理解在server中有個counter，每處理一個請求加1，1秒後counter=QPS。
4.TPS
每秒鐘處理完的事務次數，一般TPS是對整個系統來講的。一個應用系統1s能完成多少事務處理，一個事務在分散式處理中，可能會對應多個請求，對於衡量單個介面服務的處理能力，用QPS比較多
5.併發數
併發數：系統同時處理的request/事務數，指系統可以同時承載的正常使用系統功能的使用者的數量。與吞吐量相比，併發使用者數是一個更直觀但也更籠統的效能指標。
6.響應時間（RT）
響應時間：一般取平均響應時間，響應時間，處理一次請求所需要的平均處理時間
7.關係
QPS(TPS)=併發數/平均響應時間、併發數=QPS(TPS)*平均響應時間。 一個系統吞吐量通常由QPS(TPS)、併發數兩個因素決定，在應用場景訪問壓力下，只要某一項達到系統最高值或超標，系統超負荷工作、上下文切換、記憶體等其他消耗導致系統性能下降，系統的吞吐量會下降反而會下降。
8.系統吞吐量評估
指單位時間內系統處理使用者的請求數，從業務角度看，吞吐量可以用：請求數/秒、頁面數/秒、人數/天或處理業務數/小時等單位來衡量，從網路角度看，吞吐量可以用：位元組/秒來衡量，對於互動式應用來說，吞吐量指標反映的是伺服器承受的壓力，它能夠說明系統的負載能力
9. 計算關係
QPS = 併發量 / 平均響應時間
併發量 = QPS * 平均響應時間
QPS提升帶來什麼？
QPS提升說明單臺伺服器處理能力提升，如果QPS提升1倍，伺服器資源減少1半，或者說伺服器不變可以支撐2倍的請求量。 如何提升QPS？
-
減少CPU的使用時間（哪些程式碼會消耗CPU：迴圈、字串拼接\查詢\替換、編碼\解碼、序列化\反序列化、壓縮）
-
增加CPU的數量
-
減少同步鎖 （如果CPU不能被壓到85%以上，並且此時的QPS已經達到了峰值，則說明另有瓶頸，接下去關注記憶體
RT提升帶來什麼？ 響應速度提升說明單詞請求的處理速度提升，使用者感覺任務處理速度更快，系統反應速度更快。當然在處理能力不變的情況下，RT的提升必然會提升QPS。 如何提升RT？
-
減少I/O的響應時間
-
減少I/O的呼叫次數
-
減少CPU使用時間（當然在I/O佔大頭的應用裡，這方面優化效果肯定不明顯）
參考文獻