一．系統吞度量要素：
乙個系統的吞度量（承壓能力）與request對cpu的消耗、外部介面、io等等緊密關聯。
單個reqeust 對cpu消耗越高，外部系統介面、io影響速度越慢，系統吞吐能力越低，反之越高。
系統吞吐量幾個重要引數：qps（tps）、併發數、響應時間
qps（tps）：每秒鐘request/事務 數量
併發數： 系統同時處理的request/事務數
理解了上面三個要素的意義之後，就能推算出它們之間的關係：
qps（tps）= 併發數/平均響應時間
乙個系統吞吐量通常由qps（tps）、併發數兩個因素決定，每套系統這兩個值都有乙個相對極限值，在應用場景訪問壓力下，只要某一項達到系統最高值，系統的吞吐量就上不去了，如果壓力繼續增大，系統的吞吐量反而會下降，原因是系統超負荷工作，上下文切換、記憶體等等其它消耗導致系統效能下降。我們做專案要排計畫，可以多人同時併發做多項任務，也可以乙個人或者多個人序列工作，始終會有一條關鍵路徑，這條路徑就是專案的工期。
系統一次呼叫的響應時間跟專案計畫一樣，也有一條關鍵路徑，這個關鍵路徑是就是系統影響時間；
關鍵路徑是有cpu運算、io、外部系統響應等等組成。
二．系統吞吐量評估：
我們在做系統設計的時候就需要考慮cpu運算、io、外部系統響應因素造成的影響以及對系統效能的初步預估。
而通常境況下，我們面對需求，我們評估出來的出來qps、併發數之外，還有另外乙個維度：日pv。
通過觀察系統的訪問日誌發現，在使用者量很大的情況下，各個時間週期內的同一時間段的訪問流量幾乎一樣。比如工作日的每天早上。只要能拿到日流量圖和qps我們就可以推算日流量。
通常的技術方法：
1. 找出系統的最高tps和日pv，這兩個要素有相對比較穩定的關係（除了放假、季節性因素影響之外）
2. 通過壓力測試或者經驗預估，得出最高tps，然後跟進1的關係，計算出系統最高的日吞吐量。b2b中文和**面對的客戶群不一樣，這兩個客戶群的網路行為不應用，他們之間的tps和pv關係比例也不一樣。
吞吐量 併發量
併發數 吞吐量的概念最初用來衡量網路裝置的效能，後來推廣到伺服器及業務上評估系統的整體效能。一 網路裝置的併發數 吞吐量 併發數 concurrency 也叫併發連線數，指網路裝置所能處理的最大會話數量。這裡的會話數是指請求 響應一次會話。吞吐量 throughput 使用者請求是由乙個個資料報組成...
TPS 併發使用者數 吞吐量關係
主要描述了在效能測試中,關於tps 併發使用者數 吞吐量之間的關係和一些計算方法。乙個系統的吞度量 承壓能力 與request對cpu的消耗 外部介面 io等等緊密關聯。單個reqeust 對cpu消耗越高，外部系統介面 io影響速度越慢，系統吞吐能力越低，反之越高。系統吞吐量幾個重要引數 qps ...
系統吞吐量
系統吞吐量 很多情況下，筆者經常聽見許多開發人員在壓力測試中經常提及吞吐量，但經過實際溝通來看，其實大部分開發人員並不能夠準確的理解和定位系統吞吐量或者評估系統吞吐量。簡單來說，吞吐量指的就是系統在乙個指定的時間範圍能，能夠處理的實際請求數量，比如系統以秒為單位，每一秒鐘就近可以處理多少使用者請求，...