场景：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；
