1、TPS：Transactions Per Second（每秒傳輸的事物處理個數），即伺服器每秒處理的事務數。TPS包括一條訊息入和一條訊息出，加上一次使用者資料庫訪問。（業務TPS = CAPS × 每個呼叫平均TPS）

TPS是軟體測試結果的測量單位。一個事務是指一個客戶機向伺服器傳送請求然後伺服器做出反應的過程。客戶機在傳送請求時開始計時，收到伺服器響應後結束計時，以此來計算使用的時間和完成的事務個數。

一般的，評價系統性能均以每秒鐘完成的技術交易的數量來衡量。系統整體處理能力取決於處理能力最低模組的TPS值。

2、QPS：每秒查詢率QPS是對一個特定的查詢伺服器在規定時間內

對應fetches/sec，即每秒的響應請求數，也即是最大吞吐能力。

QPS與TPS的區別是什麼呢？

舉個栗子：假如一個大胃王一秒能吃10個包子，一個女孩子0.1秒能吃1個包子，那麼他們是不是一樣的呢？答案是否定的，因為這個女孩子不可能在一秒鐘吃下10個包子，她可能要吃很久。這個時候這個大胃王就相當於TPS，而這個女孩子則是QPS。雖然很相似，但其實是不同的。

學習群號：680748947，歡迎進群交流

一．系統吞吐量要素：

一個系統的吞吐量（承壓能力）與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=併發使用者數/平均響應時間。）隨著併發使用者數的增加，平均響應時間也在增加，而且平均響應時間的增加是一個指數增加曲線。而當併發數增加到很大時，每秒鐘都會有很多請求需要處理，會造成程序（執行緒）頻繁切換，反正真正用於處理請求的時間變少，每秒能夠處 理的請求數反而變少，同時使用者的請求等待時間也會變大，甚至超過使用者的心理底線。

作者：我也討厭自己
連結：https://www.jianshu.com/p/2fff42a9dfcf
來源：簡書
簡書著作權歸作者所有，任何形式的轉載都請聯絡作者獲得授權並註明出處。