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