jmeter压测过程中，TIME_WAIT很多导致请求数上不去问题解决

背景介绍

        为了摸底项目的性能，需要进行性能测试。经过一番调研之后，决定使用基于腾讯云TKE的分布式jmeter进行压测，好处是有jmeter-suite可用，搭建环境方便；容器化部署可以方便的增加pod来提升压力。

       但是在实际施压的时候，发现请求量上不去，达不到压测效果。经定位发现，容器pod上存在大量TIME_WAIT，而实际在传输数据的连接远小于设置的并发线程数：

netstat -n | awk '/^tcp/ {++state[$NF]} END {for(key in state) print key,"\t",state[key]}'

为什么会有TIME_WAIT

       这是TCP连接释放的4次挥手的过程：

1. 主动关闭连接的一方，调用close()；协议层发送FIN包
2. 被动关闭的一方收到FIN包后，协议层回复ACK；然后被动关闭的一方，进入CLOSE_WAIT状态，主动关闭的一方等待对方关闭，则进入FIN_WAIT_2状态；此时，主动关闭的一方
3. 等待
4. 被动关闭一方的应用程序，调用close操作
5. 被动关闭的一方在完成所有数据发送后，调用close()操作；此时，协议层发送FIN包给主动关闭的一方，等待对方的ACK，被动关闭的一方进入LAST_ACK状态；
6. 主动关闭的一方收到FIN包，协议层回复ACK；此时，主动关闭连接的一方，进入TIME_WAIT状态；而被动关闭的一方，进入CLOSED状态
7. 等待2MSL时间，主动关闭的一方，结束TIME_WAIT，进入CLOSED状态

       这个过程可以得到一下几个信息：

• ESTABLISHED状态，表示正在发送请求的连接，即正在施压的请求个数
• 主动关闭连接的一方最终会进入TIME_WAIT状态
• TIME_WAIT会默认等待2MSL时间后，才最终进入CLOSED状态；
• 在一个连接没有进入CLOSED状态之前，这个连接是不能被重用

哪些情况会产生这么多TIME_WAIT，怎么处理

线程数确实很多，就可能会产生大量的TIME_WAIT

       比如并行的线程数上万，由于一般是施压方主动断开连接，因此会积累大量的TIME_WAIT。建议解决方案：

• 建议使用分布式压测，将线程数分散到多台机器，这里可以使用云原生压测平台进行

jmeter的配置会影响TIME_WAIT的产生

• 建议开启该配置，使用长连接，这样会复用连接发送请求

• Ramp-up时间（秒），这个配置表示多长时间把线程全部生成，需要根据业务情况做好配置，避免一次性生成太多配置，直接把施压机器搞垮，积累较多TIME_WAIT
• Same user on each iteration，在 JMeter 中，user 就是线程，此选项的意思是说每个迭代都用相同的线程。它的影响就是单个线程多次迭代使用同一个线程，因为销毁和创建线程本身就会占用资源，可能会影响性能测试结果。建议开启

Linux本身没有设置回收使用TIME_WAIT状态的连接

       如第二节中所述，TIME_WAIT状态的连接，需要2MSL时间后才能回收端口用于创建新的连接，但是实际Linux内核配置支持快速回收TIME_WAIT状态的连接，配置可查看：

cat /etc/sysctl.conf

• net.ipv4.tcp_tw_recycle，该配置表示快速回收TIME_WAIT连接，但在NAT网络下，会导致连接失败（刚好使用的就是NAT），另外Linux 从4.12内核版本开始移除了 tcp_tw_recycle 配置，我这里的机器是4.14，因此直接注释掉
• net.ipv4.tcp_tw_reuse，表示是否允许重新应用处于TIME-WAIT状态的socket用于新的TCP连接；那么，当连接被复用了之后，延迟或者重发的数据包到达，新的连接怎么判断，到达的数据是属于复用后的连接，还是复用前的连接呢？这就需要依赖net.ipv4.tcp_timestamps字段了。复用连接后，这条连接的时间被更新为当前的时间，当延迟的数据达到，延迟数据的时间是小于新连接的时间，所以，内核可以通过时间判断出，延迟的数据可以安全的丢弃掉了。
• net.ipv4.tcp_timestamps，在重用连接的情况下，该配置能帮助操作系统识别新来的数据是旧连接的还是新连接的

实验下修改后的修过

       使用百度来实验压测，实测相同的线程下，压出来的QPS大幅提升。