Transactions Per Second（每秒傳輸的事物處理個數，或者說每秒系統接收的任務數量），系統接收到任務後會有一個處理時間。
TPS反映了系統在同一時間內能處理業務的最大能力，這個數值越高，說明系統處理能力越強。 這裡的最高值並不一定代表系統的最大處理能力，TPS會受到負載的影響，也會隨著負載的增加而逐漸增加，當系統進入繁忙期後，TPS會有所下降。而在幾分鐘以後開始出現少量的失敗案例
在壓力測試時，測試人員會主動按一定tps的量來主動發起接口請求，比如tps=50，就是每秒請求50次，獲取一個平均的響應時間（單位一般都是毫秒ms）。 壓力測試人員口中的TPS 50 200ms返回，就是指每秒測試人員主動發起50次請求，這些請求會在平均200ms返回。
一個100w訪問的服務，每天訪問集中白天8小時，每個用戶大約會請求3個接口，每天早上9點是峰值。
首先計算日均請求數（每秒）按8小時 100w訪問量、平均3個接口請求計算
每秒日均請求數=100w（訪問量）* 3（每個訪問量平均請求接口數）/8（小時）/3600（切換成秒），結果就是每秒請求100次。
按接口200ms返回，tps需要> 100 * 200/1000，即>20就行了。
如考慮日常服務的峰值，則按4 * 日均，即每秒請求400次，則tps>80即可，因此可推薦按tps=100來做接口的壓力測試。
某業務，類似秒殺型，用戶估算有2W左右，每個用戶平均請求2次接口（查詢用戶信息接口、查詢業務接口）， 這些用戶大機率會在2分鐘內會訪問我們的系統，業務要保證用戶2s能打開頁面
整個系統的總請求數=用戶（2W）* 每個用戶請求數（2次）= 40000次其次，每秒要求處理的請求數=總請求數/時間（秒） 即約350。 最後，TPS並發數量與每個請求所消耗的時間，可實際計算出每秒實際能夠處理的請求數。
TPS數量 > 總請求數 * tps返回時間【按200ms計算】/1000ms
tps>(350 * 200)/1000，具體tps>70。
因此可讓壓力測試按照tps100來壓接口，返回在200ms以內就滿足性能要求。
- 利用併發使用者數、期望響應時間，可以計算出TPS。
- TPS只是用來計算的是期望值，效能測試過程中的TPS無法單獨作為效能指標。
- TPS資料範圍理論值應在10-100之間，低於10和高於100都說明系統存在瓶頸點。
- 利用TPS與平均事務響應時間進行對比，可以分析事務數碼對執行時間的影響。例：當壓力加大，點選率/TPS曲線如果變化緩慢或者有平坦趨勢，很有可能是伺服器開始出現瓶頸。
- TPS是從客戶端角度審視伺服器處理能力，不能證明TPS可以達到什麼程度就能支援多少併發，兩者沒有必然聯絡。
- 當增大系統的壓力(或增加併發使用者數)時，吞吐率和TPS的變化曲線呈正比變化，則系統基本穩定
若壓力增大時，吞吐率的曲線增加到一定程度後出現變化緩慢，甚至平坦，同時TPS也趨於平坦，檢視系統資源使用，如果資源使用率比較高，則說明伺服器硬體資源存在問題，需要拓展硬體或者優化應用。反之，則說明7. 伺服器硬體資源不存在問題，檢視網路流量，估計網路頻寬存在問題。 - 點選率/TPS曲線出現變化緩慢或者平坦,很可能是伺服器響應時間增加，觀察伺服器資源使用情況，確定是否是伺服器問題或者應用問題