乙個系統的吞度量（承壓能力）與request對cpu的消耗、外部介面、io等等緊密關聯。單個reqeust 對cpu消耗越高，外部系統介面、io影響速度越慢，系統吞吐能力越低，反之越高。
系統吞吐量幾個重要引數：qps（tps）、併發數、響應時間
qps（tps）：每秒鐘request/事務 數量（很多人經常會把併發數和tps理解混淆）併發數： 系統同時處理的request/事務數
理解了上面三個要素的意義之後，就能推算出它們之間的關係：
qps（tps）= 併發數/平均響應時間 或者 併發數 = qps*平均響應時間舉個例子：
銀行視窗業務，早上8點上班，視窗數量為10個視窗，平均每個人辦理業務的時候為5分鐘。可以用下面的方法計算。乙個系統吞吐量通常由qps（tps）、併發數兩個因素決定，每套系統這兩個值都有乙個相對極限值，在應用場景訪問壓力下，只要某一項達到系統最高值，系統的吞吐量就上不去了，如果壓力繼續增大，系統的吞吐量反而會下降，原因是系統超負荷工作，上下文切換、記憶體等等其它消耗導致系統效能下降。併發數=10個視窗
平均響應時間為 = 5*60 秒
qps = 10/(5*60) 事務/秒
決定系統響應時間要素
我們做專案要排計畫，可以多人同時併發做多項任務，也可以乙個人或者多個人序列工作，始終會有一條關鍵路徑，這條路徑就是專案的工期。
系統一次呼叫的響應時間跟專案計畫一樣，也有一條關鍵路徑，這個關鍵路徑是就是系統影響時間；
關鍵路徑是有cpu運算、io、外部系統響應等等組成。
由前面的公式：qps（tps）= 併發數/平均響應時間 可以看出，要提高qps,我們必須做2個方面努力
2.1增加併發數
1.比如增加tomcat併發的執行緒數，開喝伺服器效能匹配的執行緒數，可以更多滿足服務請求。
2.增加資料庫的連線數，預建立合適數量的tcp連線數
3.後端服務盡量無狀態話，可以更好支援橫向擴容，滿足更大流量要求
4.呼叫鏈路上的各個系統和服務盡量不要單點，要從頭到尾都是能力對等的，不能讓其中某一點成為瓶頸。
5.rpc呼叫的盡量使用執行緒池，預先建立合適的連線數。
2.2減少平均響應時間
1.請求盡量越前結束，越好，這樣壓力就不要穿透到後面的系統上，可以在各個層上加上快取
2.流量消峰。放行適當的流量，處理不了的請求直接返回錯誤或者其他提示。和水壩道理很類似
3.減少呼叫鏈
4.優化程式
5.減少網路開銷，適當使用長連線
6.優化資料庫，建立索引
最後，要優化的地方還有很多，上面只是列舉常見一些要注意的地方，優化的指導原則就是增加併發數 和減少平均響應時間
系統吞吐量
系統吞吐量 很多情況下，筆者經常聽見許多開發人員在壓力測試中經常提及吞吐量，但經過實際溝通來看，其實大部分開發人員並不能夠準確的理解和定位系統吞吐量或者評估系統吞吐量。簡單來說，吞吐量指的就是系統在乙個指定的時間範圍能，能夠處理的實際請求數量，比如系統以秒為單位，每一秒鐘就近可以處理多少使用者請求，...
系統吞吐量
一 系統吞度量要素 乙個系統的吞度量 承壓能力 與request對cpu的消耗 外部介面 io等等緊密關聯。單個reqeust 對cpu消耗越高，外部系統介面 io影響速度越慢。系統吞吐能力越低，反之越高。系統吞吐量幾個重要引數 qps tps 併發數 響應時間 qps tps 每秒鐘request...
springboot專案提高吞吐量
最近學習了壓力測試，發現自己做的專案吞吐量低，便對專案進行了一些優化。前後端分離開發 採用頁面靜態化，前端人員可以將頁面存在瀏覽器快取中。非分離開發 採用頁面快取，後端人員可以將返回給客戶端的頁面，提前渲染頁面存於redis快取中，設定1分鐘的過期時間。將物件id作為key物件資訊作為value存入...