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