性能测试实战分享1---TPS上升后下降

场景:30个并发,单台jmeter压测;客户端-Windows系统,服务端-linux系统;

问题:TPS上升后下降,且下降为高峰TPS的四分之一左右;

原因:压测机tcp连接端口占用过多超2万7千多,且大部分TCP连接都是time_wait状态,顾tcp连接端口不足;

解决方案:采用分布式压测,增加端口号;

分析思路
*第一步:*分析客户端和服务端的性能,看是否有性能瓶颈(CPU,内存,磁盘,网络)
*第二步:*再分析客户端和服务端的端口是否用尽
*第三步:*最后分析客户端和服务端的Java堆栈日志,分析原因

本次测试的经验分享:
1、通过jemter-permon监控分析服务端的硬件性能,看是否有性能瓶颈(CPU,内存,磁盘,网络),结果:未发现硬件性能瓶颈;通过任务管理器查看客户端(Windows服务器),也未发现硬件性能瓶颈。

2、通过jstack分析服务端的Java堆栈信息,因为一直没有获取到对应服务Java的pid,所以也没有一直分析(后期分析有结果再和大家分享);通过jstack分析客户端的Java堆栈信息,发现如下错误:

“java.lang.Thread.State: RUNNABLE
 at java.net.DualStackPlainSocketImpl.connect0(Native Method)
 at java.net.DualStackPlainSocketImpl.socketConnect(Unknown Source)
 at java.net.AbstractPlainSocketImpl.doConnect(Unknown Source)
 - locked <0x0000000776a7fff8> (a java.net.DualStackPlainSocketImpl)
 at java.net.AbstractPlainSocketImpl.connectToAddress(Unknown Source)
 at java.net.AbstractPlainSocketImpl.connect(Unknown Source)
 at java.net.PlainSocketImpl.connect(Unknown Source)
 at java.net.SocksSocketImpl.connect(Unknown Source)
 at java.net.Socket.connect(Unknown Source)”

初步定位可能跟端口号用尽有关;

3、通过netstat -ano|findstr 443|find /C “TCP”(window系统)分析客户端tcp端口的使用个数,通过netstat -ano|findstr 443|findstr TCP分析客户端tcp端口的使用情况。
结果:发现TCP端口使用2万7千多,且大部分都是time_wait状态。

4、以此判断tcp连接端口不足,采用分布式来压测,TCP曲线图基本正常。

5、为啥30个并发就把TCP端口占用这么多,需要进一步详细分析下。

问题监控现象图:
性能测试实战分享1---TPS上升后下降_第1张图片

问题解决恢复监控图:
性能测试实战分享1---TPS上升后下降_第2张图片

说明
欢迎对于测试志同道合的人加入,大家一起沟通交流!
QQ群:775460627
个人微信:wxid_ptea4d8gx4tx12;

性能测试实战分享1---TPS上升后下降_第3张图片

你可能感兴趣的:(jmeter,性能分析,linux,压力测试,性能优化)