1、獲得TPS插件
安裝插件管理器
1)、進入https://jmeter-plugins.org/install/Install/ 下載plugins-manager.jar
2)、將 plugins-manager.jar 放到 _…\apache-jmeter-3.2\lib\ext_目錄下。
3)、重啟 ApacheJMeter
4)、菜單欄上會多出一個“Plugins Manager”的按鈕，點擊可以查看各種插件
5)、添加插件：3 Basic Graph：windows下可用的實時tps和響應時間的插件
2、添加后，記得使用調度器——每秒50個並發，持續60秒，觀察TPS
3、TPS，執行一次事務（包括請求、請求服務器、等待服務器返回等等，比如一個TPS事務，可能觸發3個QPS請求）
PS：一秒鍾處理的事務數。TPS值越大，一秒鍾處理的事務數就越多，說明處理速度越快，軟件的效率就越好。
一、TPS：Transactions Per Second（每秒傳輸的事物處理個數），即服務器每秒處理的事務數。TPS包括一條消息入和一條消息出，加上一次用戶數據庫訪問。（業務TPS = CAPS × 每個呼叫平均TPS）
TPS是軟件測試結果的測量單位。一個事務是指一個客戶機向服務器發送請求然后服務器做出反應的過程。客戶機在發送請求時開始計時，收到服務器響應后結束計時，以此來計算使用的時間和完成的事務個數。
一般的，評價系統性能均以每秒鍾完成的技術交易的數量來衡量。系統整體處理能力取決於處理能力最低模塊的TPS值。
二、QPS：每秒查詢率QPS是對一個特定的查詢服務器在規定時間內所處理流量多少的衡量標准，在因特網上，作為域名系統服務器的機器的性能經常用每秒查詢率來衡量。
對應fetches/sec，即每秒的響應請求數，也即是最大吞吐能力。
4、吞吐量與並發數
一個接口一秒鍾能承受50個並發，不代表可以有50個吞吐量；
吞吐量與系統性能息息相關；
設置長時間跑接口，比如1秒50並發，持續60秒——發現實際接口請求數1461個，時間60秒，TPS參數較穩定；
TPS大概在23左右，所以當前這個接口，系統能處理的事務在23個左右
TPS=請求數/時間
QPS/TPS/並發量/系統吞吐量的概念
QPS: 每秒鍾處理完請求的次數；注意這里是處理完。具體是指發出請求到服務器處理完成功返回結果。可以理解在server中有個counter，每處理一個請求加1，1秒后counter=QPS。
TPS：每秒鍾處理完的事務次數，一般TPS是對整個系統來講的。一個應用系統1s能完成多少事務處理，一個事務在分布式處理中，可能會對應多個請求，對於衡量單個接口服務的處理能力，用QPS比較多。
並發量：系統能同時處理的請求數
RT：響應時間，處理一次請求所需要的平均處理時間
計算關系：
QPS = 並發量 / 平均響應時間
並發量 = QPS * 平均響應時間
5、jmeter限制，最多100-200個並發，可以嘗試使用LR，LR可監測jvm參數
6、Vu和TPS換算 ——很有用的文章 https://blog.csdn.net/taric_ma/article/details/77285522
TPS是每秒事務數，但是事務是要靠虛擬用戶做出來的，假如1個虛擬用戶在1秒 內完成1筆事務，那么TPS明顯就是1；如果某筆業務響應時間是1ms,那么1個用戶在1秒內能完成1000筆事務，TPS就是1000了；如果某筆業務 響應時間是1s,那么1個用戶在1秒內只能完成1筆事務，要想達到1000TPS，至少需要1000個用戶；因此可以說1個用戶可以產生 1000TPS，1000個用戶也可以產生1000TPS，無非是看響應時間快慢。
7、性能測試策略
做性能測試需要一套標准化流程及測試策略，並發用戶數只是指標考慮的一個，在做負載測試的時候，一般都是按照梯度施壓的方式去加用戶數，而不是在沒 有預估的情況下，一次加幾萬個用戶，，交易失敗率非常高，響應時間非常長，已經超過了使用者忍受范圍內，這樣做沒有多大的意義，這就好比“有多少錢可以干多少事”一樣，需要選擇相關的策略。
8、總結
- 系統的性能由TPS決定，跟並發用戶數沒有多大關系。在同樣的TPS下，可以由不同的用戶數去壓（通過加思考時間設置）。
- 系統的最大TPS是一定的（在一個范圍內），但並發用戶數不一定，可以調整。
- 建議性能測試的時候，不要設置過長的思考時間，以最壞的情況下對服務器施壓。
- 一般情況下，大型系統（業務量大、機器多）做壓力測試，5000個用戶並發就夠了，中小型系統做壓力測試，1000個用戶並發就足夠了。