https://blog.csdn.net/lzqinfen/article/details/46820673
tps抖動厲害的原因？
突然增加成倍的用戶，如果性能表現良好，TPS應該成倍增加，響應時間不變；如果性能表現一般，TPS增加一些，響應時間增加一些；如果性能表現不好，則TPS沒啥變化，響應時間增加，而且可能出現抖動現象，因為用戶太多，處理不過來。是正常現象
1：觀察資源抖不抖動，是否資源的抖動導致TPS抖動
2：FULL GC太過頻繁，查看JVM參數配置
3：pacing設置過大
4、java編寫的測試腳本，負載機JVM堆內存太小
先說下問題：
我在做性能測試時，使用JMeter搞了100個並發，以100TPS的壓力壓測十分鍾，但壓力一直出現波動，而且出現波動時JMeter十分卡，如下圖：
周期性TPS波動
各種推測：
所以開始找環境的各種原因，起初以為是JMeter的連接被“劫持”了，不然JMeter也不會卡的。所以，花了整整一下午時間，去排除壓測機環境、被壓測環境（TCP連接數、程序上的問題等等），但一直沒找到原因。后來，換成LR后，壓測正常。所以開始懷疑是JMeter自身的問題。
原因找到：
后來想起來，我被測場景的腳本是老的腳本，也是在JMeter2.8上的，然后我現在用的JMeter是2.13，難道是腳本的兼容性問題？
問題解決：
各種替換，最后才定位到了是CSV Data Set Config的問題，只要我用2.8的腳本上的CSV Data Set Config進行參數化，哪怕是這個參數我沒有用，一壓測就出現TPS波動；我禁用后，新建了一個CSV Data Set Config，所有數據保持不變，再次壓測，OK！ 這個坑真大！希望Apache組織能夠修改下，肯定是老版本的CSV Data Set Config在新版本的JMeter壓測時，調度存在問題，導致本地的壓力不穩定，而且關鍵的是，這個導致JMeter太卡了。問題解決后的壓力如下：穩穩的，我要穩穩的幸福~
下圖很穩定了，波動在3TPS范圍
還有其他坑：
PS：另外，再給大家補充個坑，就是JMeter插件的資源監控問題，將agent放到Linux上去監控資源，cpu和內存都沒什么問題，但如果你監控tcp的連接話，就要注意了，這個監控可以吃掉15%左右cpu資源，4核單板的喔，而且是sys的cpu高很多。應該是這塊監控的算法不夠優化，占用了太多的資源。請各位JMeter使用者千萬注意咯！
jmeter之性能測試TPS解析：https://blog.csdn.net/u011197146/article/details/83273879