Waiting for server respnse 耗时过长原因排查

Myth丶恋晨 2024-03-31 10:39 63阅读 0赞

## 背景 ##

开发了一个导入接口，测试过程中发现导入压缩包24M时，耗时50多秒。觉得这个时间太长了，可能存在问题，于是开始了漫长的排查之旅。

## 查看接口时间 ##

通过Chrome DevTools 查看接口请求信息，发现接口时间主要消耗在发送数据（Request sent）和等待服务器响应（Waiting for server respnse）两部分。

Request sent：平均在31s  
Waiting for server respnse：平均18s  
![在这里插入图片描述][61dbd849e22c401cb565820bbe1f6111.png]  
Request sent时间属于正常偏慢，因为发送数据受网络上行带宽限制，暂时也没办法做太大的优化。  
Waiting for server respnse时间有很大的问题，因为接口中只做了简单的操作，复杂的数据处理都是异步执行的，所以问题应该在服务端。

## 排查接口问题 ##

怀疑是接口请求问题后，就使用arthas trace 查看接口详细耗时。

docker exec -it xxx java -jar /arthas/arthas-boot.jar
    [INFO] arthas-boot version: 3.5.1
    [INFO] Found existing java process, please choose one and input the serial number of the process, eg : 1. Then hit ENTER.
    * [1]: 10 org.springframework.boot.loader.JarLauncher
    
    [INFO] arthas home: /opt/arthas
    [INFO] Try to attach process 10
    [INFO] Attach process 10 success.
    [INFO] arthas-client connect 127.0.0.1 3658
      ,---.  ,------. ,--------.,--.  ,--.  ,---.   ,---.                           
     /  O  \ |  .--. ''--.  .--'|  '--'  | /  O  \ '   .-'                          
    |  .-.  ||  '--'.'   |  |   |  .--.  ||  .-.  |`.  `-.                          
    |  | |  ||  |\  \    |  |   |  |  |  ||  | |  |.-'    |                         
    `--' `--'`--' '--'   `--'   `--'  `--'`--' `--'`-----'                          
                                                                                    
    
    wiki       https://arthas.aliyun.com/doc                                        
    tutorials  https://arthas.aliyun.com/doc/arthas-tutorials.html                  
    version    3.5.1                                                                
    main_class                                                                      
    pid        10                                                                   
    time       2022-11-23 19:07:06                                                  
    
    [arthas@10]$ trace xxx.XXXController test  -n 5 --skipJDKMethod false 
    Press Q or Ctrl+C to abort.
    Affect(class count: 2 , method count: 2) cost in 601 ms, listenerId: 1
    `---ts=2022-11-24 13:44:28;thread_name=http-nio-9001-exec-17;id=bd;is_daemon=true;priority=5;TCCL=org.xxx.xxxClassLoader@300aa927
        `---[211.492528ms] xxx.XXXController$$EnhancerBySpringCGLIB$$103cd3e4:test()
            `---[166.654272ms] org.xxx.MethodInterceptor:intercept() #57
                `---[102.043649ms] com.xxx.XXXController:test()
                    +---[101.125313ms] com.xxx.XXXService:importUser() #359
                    `---[0.754306ms] com.xxx.XXXBuilder:success() #57

根据arthas trace日志显示，接口耗时在200ms左右，这才是符合预期的时间。没有找到具体问题，只能代码走查一遍。接口逻辑其实很清晰，先校验文件格式大小，然后创建异步任务（插入一条数据），最后执行异步任务。因为有异步任务，所以整个接口耗时应该最多几百毫秒，初步判断arthas trace的结果正确合理。

## 排查网关问题 ##

既然接口实现没有问题，那就往上游排查，查看网关是否存在问题。查看网关接口请求和返回时间和刚才arthas trace时间相差无几，排除了网关的问题。

## 排查SLB问题 ##

网关没问题只能在往上排查问题，测试了另一个环境B发现是相对正常的，Waiting for server respnse 时间在600ms左右。  
![在这里插入图片描述][43ff3d2831534af58420a4613b454764.png]  
对比讨论了下两个环境的差异，发现有问题的环境A相比正常的环境B多了一层SLB负载均衡，怀疑可能是这个问题。网上查了相关资料，也没有显示SLB有出现过这种情况。

于是让运维先关闭SLB负载均衡验证一下情况，修改SLB配置后需要一小会才能生效，结果显示关掉SLB接口请求时间还是有问题， 因此也不是SLB的问题，于是只是剩下Nginx了。

## 排查Nginx问题 ##

排查了一下午没有结果，然后就先去吃饭休息，踢踢桌面足球放松一下。

放松回来后，开始排查了Nginx配置，尝试重启ng，修改buffer大小都无济于事。扫到ng配置的时候发现ng做了一次负载均衡，而且服务器地址配置的是公网ip，猜测可能是这个问题，死马当成活马医，随便试试看。修改为内网地址，然后重启ng后验证发现正常了。就这样正常了。花了大半天时间，总算解决了。后来复盘讨论猜测，应该是ng接收到文件后，通过负载均衡走公网ip转了一圈回来导致Waiting for server respnse 耗时过长。

一不小心就有坑。

THE END.

[61dbd849e22c401cb565820bbe1f6111.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/03/31/43bf34e509474479bbd81e3bf303c649.png
[43ff3d2831534af58420a4613b454764.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/03/31/2d0c0ac1f8584085ac6e325302a0ff3b.png