记一次并发/接口延迟问题的解决思路

博主是做搜索服务的，框架选型tornado，采用单进程+线程部署模式，有一次接口迁移，接了线上大流量请求过来，发现APM日志接口性能明显下降了，然后就开始了疯狂排查。

1.接口性能日志，排查APM接口性能监控日志（我部署了这个服务，如果你没有，你在接口层面打文件日志监测接口性能也可以）
2.系统层面，排查Linux层面TIME_WAIT的情况，因为一个request进来的时候，一定有个端口跟你http开放的（用3001举例好了）端口保持通信（socket短链接,四次握手）

如果发现你的端口听通信数量巨大，且都处于TIME_WAIT状态，这个时候你就要考虑修改sysctl -a里面的配置了，我这里贴出常见的网上修改配置。

# file : /etc/sysctl.conf
net.ipv4.tcp_tw_reuse = 1
# 开启TCP连接中TIME-WAIT sockets的快速回收
net.ipv4.tcp_tw_recycle = 1
# 在高并发情况下，连接创建时候会考虑复用相应的time_wait连接。而一般情况下，TIME_WAIT创建时间必须超过一秒，且连接的时间戳是递增的时候才会被复用。和标准相比，几秒的timewait已经远远小于linux原生的60s，可以大大提
升我们的qps。
# 不建议开启，在ab高并发测试下，会造成2ms的接口延迟突然跳到2000ms的可能
net.ipv4.tcp_timestamps=0
kernel.sysrq = 1
net.ipv4.ip_local_port_range=1024 65535

修改后 sysctl -p生效配置
3.系统层面，自己做一次并发测试检查连接数减少没有。
4.网络层面，直接在远程机器上做curl -o /dev/null -s -w "time_connect: %{time_connect}\ntime_starttransfer: %{time_starttransfer}\ntime_total: %{time_total}\n" URL
请求去测试接口的响应时间，排除是否网络波动影响的延迟（一般概率很低，除非你服务器之间VPC管道通信，高速通道等）
5.框架层面，每个框架都有不同的并发处理方案，检查你的框架是否有坑，比如tornado自带ioLoop，如果在代码里面使用了await会阻塞整个ioloop，所以改成多进程启动速度一下就上来了
6.代码层面，自己打断点，检查是否有耗性能的代码，注意，大并发情况下别小看那10ms，一下就会撑爆你的机器

关于如何测试

建议使用AB做压力测试，命令行用法
ab -n 1 -c 20 -t 10 URL'

— 2019年08月21日13:26:25 更新 —

# (1) 开启这个参数可能导致ssh连不上(占用TCP连接)
# (2) 如果服务器瓶颈足够大的话，强烈不建议开启！
# 解释： 60s内同一源ip主机的socket connect请求中的timestamp必须是递增的。
也就是说服务器打开了 tcp_tw_reccycle了，就会检查时间戳，
如果对方发来的包的时间戳是乱跳的或者说时间戳是滞后的，这样服务器肯定不会回复，
所以服务器就把带了“倒退”的时间戳的包当作是“recycle的tw连接的重传数据，不是新的请求”，
于是丢掉不回包，就出现了开始说的syn不响应。

net.ipv4.tcp_timestamps=0