LoadRunner效能測試指標 TPS（Transaction per Second）總結

內容為轉載，具體情況還要具體參考，實踐才能出真理
TPS(Transaction per Second)定義

TPS是Transactions Per Second 的縮寫，也就是事務數/秒。它是軟體測試結果的測量單位。一個事務是指一個客戶機向伺服器發送請求然後伺服器做出反 應的過程。客戶機在發送請求時開始計時， 收到伺服器響應後結束計時，以此來計算使用的時間和完成的事務數，最終利用這些資訊來估計得分。 TPS（Transaction per Second）作用

反映了系統在同一時間內能處理業務的最大能力，這個資料越高，說明系統處理能力越強。描述（看到系統的TPS隨著時間的變化逐漸層大，而在不到多少分鐘的時候系統每秒可以處理多少個事務。這裡的最高值並不一定代表系統的最大處理能力，TPS會受到負載的影響，也會隨著負載的增加而逐漸增加，當系統進入繁忙期後，TPS會有所下降。而在幾分鐘以後開始出現少量的失敗事務） TPS（Transaction per Second）局限性 TPS（Transaction per Second）是從用戶端角度審視伺服器處理能力，並不是說TPS可以達到什麼程度就能支援多少並發（例如一個業務100個交易，另一個業務10個交易）。 TPS=指令碼運行期間所有事務總數/指令碼運行時間長度，如果使用集合點策略，在指令碼執行前的等待時間過程中，伺服器沒有處理事務，那麼這個時候的TPS和理想中的結果不一致。 限制TPS的原因：伺服器本身效能、代碼結構、用戶端施加的壓力以及網卡等。 TPS（Transaction per Second）與回應時間的關係 TPS（Transaction per Second）和回應時間在理想狀態下都是額定值。如果20個入口，並發數只有10的時候，TPS就是10，而回應時間始終都是1，說明並發不夠，需要增加並發數達到TPS的峰值。 如果增加到100並發，則造成了線程等待，引起平均回應時間從1秒變成3秒，TPS也從20下降到9；TPS和回應時間都是單獨計算出來的，兩者不是互相計算出來的。 回應時間和TPS在宏觀上是反比的關係，但是兩者之間沒有直接關係。 TPS（Transaction per Second）在效能測試中的作用 一個系統的輸送量（承壓能力）與request對CPU的消耗、外部介面、IO等緊密關聯。單個request對CPU消耗越高，外部系統介面、IO影響速度越慢，系統吞吐能力越低，反之越高。 系統輸送量幾個重要參數：TPS、並發數、回應時間（TPS=並發數/平均回應時間） 利用TPS計算系統最高日輸送量： 找出系統最高TPS和日PV，這兩個要素有相對比較穩定的關係。 通過壓力測試或者經驗評估，得出最高TPS，然後跟進1的關係，計算出系統最高日輸送量。例如：B2B中文和淘寶對的客戶群不一樣，這兩個客戶群的網路行為不應用，他們之間的ＴＰＳ和ＰＶ關係比例也不一樣。 淘寶    淘寶的ＴＰＳ和ＰＶ之間的關係通常為，最高ＴＰＳ：ＰＶ大約為１：　１１＊３６００（相當於按最高ＴＰＳ訪問１１個小時，這個是商品詳情的情境，不同的應用情境會有一些不同）

B）B2B中文站

B2B的TPS和PV之間的關係不同的系統不同的應用情境比例變化比較大，粗數量級估計在1 ： 8個小時左右的關係（09年對offerdetail的流量分析資料）。旺鋪和offerdetail這兩個比例相差很大，可能是因為爬蟲暫的比例較高的原因導致。

在淘寶環境下，假設我們壓力測試出的TPS為100，那麼這個系統的日輸送量=100*11*3600=396萬

這個是在簡單（單一url）的情況下，有些頁面，一個頁面有多個request，系統的實際輸送量還要小。      TPS與其他效能指標的關係

TPS和並發虛擬使用者數（U_concurrent)、Loadrunner讀取的交易回應時間（T_response）之間有以下關係（穩定運行情況下）：TPS=U_concurrent / (T_response+T_think)。 TPS（Transaction per Second）總結 利用並發使用者數、期望回應時間，可以計算出TPS。 TPS只是用來計算的是期望值，效能測試過程中的TPS無法單獨作為效能指標。 TPS資料範圍理論值應在10-100之間，低於10和高於100都說明系統存在瓶頸點。 利用TPS與平均事務回應時間進行對比，可以分析事務數位對執行時間的影響。例：當壓力加大，點擊率/TPS曲線如果變化緩慢或者有平坦趨勢，很有可能是伺服器開始出現瓶頸。 TPS是從用戶端角度審視伺服器處理能力，不能證明TPS可以達到什麼程度就能支援多少並發，兩者沒有必然聯絡。