tps抖动

 

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波动

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范围
tps抖动

还有其他坑:

PS:另外,再给大家补充个坑,就是JMeter插件的资源监控问题,将agent放到Linux上去监控资源,cpu和内存都没什么问题,但如果你监控tcp的连接话,就要注意了,这个监控可以吃掉15%左右cpu资源,4核单板的喔,而且是sys的cpu高很多。应该是这块监控的算法不够优化,占用了太多的资源。请各位JMeter使用者千万注意咯!

 

 

 

jmeter之性能测试TPS解析:https://blog.csdn.net/u011197146/article/details/83273879

 

上一篇:吞吐量(TPS)、QPS、并发数、响应时间(RT)概念


下一篇:阿里如何实现秒级百万TPS?搜索离线大数据平台架构解读