一．系統吞度量要素：
一個系統的吞度量（承壓能力）與request對CPU的消耗、外部接口、IO等等緊密關聯。單個reqeust 對CPU消耗越高，外部系統接口、IO影響速度越慢，系統吞吐能力越低，反之越高。
系統吞吐量幾個重要參數：QPS（TPS）、並發數、響應時間
QPS（TPS）：每秒鍾request/事務 數量
並發數： 系統同時處理的request/事務數
響應時間： 一般取平均響應時間
（很多人經常會把並發數和TPS理解混淆）
理解了上面三個要素的意義之后，就能推算出它們之間的關系：
QPS（TPS）= 並發數/平均響應時間 或者 並發數 = QPS*平均響應時間
一個典型的上班簽到系統，早上8點上班，7點半到8點的30分鍾的時間里用戶會登錄簽到系統進行簽到。公司員工為1000人，平均每個員上登錄簽到系統的時長為5分鍾。可以用下面的方法計算。
QPS = 1000/(30*60) 事務/秒
平均響應時間為 = 5*60 秒
並發數= QPS*平均響應時間 = 1000/(30*60) *(5*60)=166.7
一個系統吞吐量通常由QPS（TPS）、並發數兩個因素決定，每套系統這兩個值都有一個相對極限值，在應用場景訪問壓力下，只要某一項達到系統最高值，系統的吞吐量就上不去了，如果壓力繼續增大，系統的吞吐量反而會下降，原因是系統超負荷工作，上下文切換、內存等等其它消耗導致系統性能下降。
決定系統響應時間要素
我們做項目要排計划，可以多人同時並發做多項任務，也可以一個人或者多個人串行工作，始終會有一條關鍵路徑，這條路徑就是項目的工期。
系統一次調用的響應時間跟項目計划一樣，也有一條關鍵路徑，這個關鍵路徑是就是系統影響時間；
關鍵路徑是有CPU運算、IO、外部系統響應等等組成。
二．系統吞吐量評估：
我們在做系統設計的時候就需要考慮CPU運算、IO、外部系統響應因素造成的影響以及對系統性能的初步預估。
而通常境況下，我們面對需求，我們評估出來的出來QPS、並發數之外，還有另外一個維度：日PV。
通過觀察系統的訪問日志發現，在用戶量很大的情況下，各個時間周期內的同一時間段的訪問流量幾乎一樣。比如工作日的每天早上。只要能拿到日流量圖和QPS我們就可以推算日流量。
通常的技術方法：
1. 找出系統的最高TPS和日PV，這兩個要素有相對比較穩定的關系（除了放假、季節性因素影響之外）
2. 通過壓力測試或者經驗預估，得出最高TPS，然后跟進1的關系，計算出系統最高的日吞吐量。B2B中文和淘寶面對的客戶群不一樣，這兩個客戶群的網絡行為不應用，他們之間的TPS和PV關系比例也不一樣。
A)淘寶
淘寶流量圖：
淘寶的TPS和PV之間的關系通常為 最高TPS：PV大約為 1 : 11*3600 （相當於按最高TPS訪問11個小時，這個是商品詳情的場景，不同的應用場景會有一些不同）
B) B2B中文站
B2B的TPS和PV之間的關系不同的系統不同的應用場景比例變化比較大，粗略估計在1 : 8個小時左右的關系（09年對offerdetail的流量分析數據）。旺鋪和offerdetail這兩個比例相差很大，可能是因為爬蟲暫的比例較高的原因導致。
在淘寶環境下，假設我們壓力測試出的TPS為100，那么這個系統的日吞吐量=100*11*3600=396萬
這個是在簡單（單一url）的情況下，有些頁面，一個頁面有多個request，系統的實際吞吐量還要小。
無論有無思考時間（T_think），測試所得的TPS值和並發虛擬用戶數(U_concurrent)、Loadrunner讀取的交易響應時間（T_response）之間有以下關系（穩定運行情況下）：
TPS=U_concurrent / (T_response+T_think)。
並發數、QPS、平均響應時間三者之間關系
上圖橫坐標是並發用戶數。綠線是CPU使用率；紫線是吞吐量，即QPS；藍線是時延。
開始，系統只有一個用戶，CPU工作肯定是不飽合的。一方面該服務器可能有多個cpu，但是只處理單個進程，另一方面，在處理一個進程中，有些階段可能是IO階段，這個時候會造成CPU等待，但是有沒有其他請 求進程可以被處理）。隨着並發用戶數的增加，CPU利用率上升，QPS相應也增加（公式為QPS=並發用戶數/平均響應時間。）隨着並發用戶數的增加，平均響應時間也在增加，而且平均響應時間的增加是一個指數增加曲線。而當並發數增加到很大時，每秒鍾都會有很多請求需要處理，會造成進程（線程）頻繁切換，反正真正用於處理請求的時間變少，每秒能夠處理的請求數反而變少，同時用戶的請求等待時間也會變大，甚至超過用戶的心理底線。