场景：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端口占用这么多，需要进一步详细分析下。

问题监控现象图：

问题解决恢复监控图：

说明
欢迎对于测试志同道合的人加入，大家一起沟通交流！
QQ群：775460627
个人微信：wxid_ptea4d8gx4tx12；