TPS 併發使用者數吞吐量關係

主要描述了在效能測試中,關於tps、併發使用者數、吞吐量之間的關係和一些計算方法。

乙個系統的吞度量（承壓能力）與request對cpu的消耗、外部介面、io等等緊密關聯。

單個reqeust 對cpu消耗越高，外部系統介面、io影響速度越慢，系統吞吐能力越低，反之越高。

系統吞吐量幾個重要引數：qps（tps）、併發數、響應時間

qps（tps）：每秒鐘request/事務數量

併發數：系統同時處理的request/事務數

（很多人經常會把併發數和tps理解混淆）

理解了上面三個要素的意義之後，就能推算出它們之間的關係：

qps（tps）= 併發數/平均響應時間

乙個系統吞吐量通常由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、平均響應時間三者之間關係

TPS 併發使用者數 吞吐量關係