LoadRunner效能測試指標 TPS（Transaction per Second）總結
阿新 • • 發佈：2019-01-01
內容為轉載，具體情況還要具體參考，實踐才能出真理
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可以達到什麼程度就能支援多少併發，兩者沒有必然聯絡。