快捷導(dǎo)航

Waiting for server respnse耗時過長原因排查及解決

更新時間：2023年05月24日 09:03:00 作者：iiopsd

這篇文章主要給大家介紹了關(guān)于Waiting for server respnse耗時過長原因排查及解決的相關(guān)資料,文中將解決的辦法介紹的非常詳細(xì),對大家的學(xué)習(xí)或者工作具有一定的參考學(xué)習(xí)價值,需要的朋友可以參考下

背景

開發(fā)了一個導(dǎo)入接口，測試過程中發(fā)現(xiàn)導(dǎo)入壓縮包24M時，耗時50多秒。覺得這個時間太長了，可能存在問題，于是開始了漫長的排查之旅。

查看接口時間

通過Chrome DevTools 查看接口請求信息，發(fā)現(xiàn)接口時間主要消耗在發(fā)送數(shù)據(jù)（Request sent）和等待服務(wù)器響應(yīng)（Waiting for server respnse）兩部分。

Request sent：平均在31s

Waiting for server respnse：平均18s

Request sent時間屬于正常偏慢，因?yàn)榘l(fā)送數(shù)據(jù)受網(wǎng)絡(luò)上行帶寬限制，暫時也沒辦法做太大的優(yōu)化。
Waiting for server respnse時間有很大的問題，因?yàn)榻涌谥兄蛔隽撕唵蔚牟僮?，?fù)雜的數(shù)據(jù)處理都是異步執(zhí)行的，所以問題應(yīng)該在服務(wù)端。

排查接口問題

懷疑是接口請求問題后，就使用arthas trace 查看接口詳細(xì)耗時。

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

根據(jù)arthas trace日志顯示，接口耗時在200ms左右，這才是符合預(yù)期的時間。沒有找到具體問題，只能代碼走查一遍。接口邏輯其實(shí)很清晰，先校驗(yàn)文件格式大小，然后創(chuàng)建異步任務(wù)（插入一條數(shù)據(jù)），最后執(zhí)行異步任務(wù)。因?yàn)橛挟惒饺蝿?wù)，所以整個接口耗時應(yīng)該最多幾百毫秒，初步判斷arthas trace的結(jié)果正確合理。

排查網(wǎng)關(guān)問題

既然接口實(shí)現(xiàn)沒有問題，那就往上游排查，查看網(wǎng)關(guān)是否存在問題。查看網(wǎng)關(guān)接口請求和返回時間和剛才arthas trace時間相差無幾，排除了網(wǎng)關(guān)的問題。

排查SLB問題

網(wǎng)關(guān)沒問題只能在往上排查問題，測試了另一個環(huán)境B發(fā)現(xiàn)是相對正常的，Waiting for server respnse 時間在600ms左右。

對比討論了下兩個環(huán)境的差異，發(fā)現(xiàn)有問題的環(huán)境A相比正常的環(huán)境B多了一層SLB負(fù)載均衡，懷疑可能是這個問題。網(wǎng)上查了相關(guān)資料，也沒有顯示SLB有出現(xiàn)過這種情況。

于是讓運(yùn)維先關(guān)閉SLB負(fù)載均衡驗(yàn)證一下情況，修改SLB配置后需要一小會才能生效，結(jié)果顯示關(guān)掉SLB接口請求時間還是有問題，因此也不是SLB的問題，于是只是剩下Nginx了。

排查Nginx問題

排查了一下午沒有結(jié)果，然后就先去吃飯休息，踢踢桌面足球放松一下。

放松回來后，開始排查了Nginx配置，嘗試重啟ng，修改buffer大小都無濟(jì)于事。掃到ng配置的時候發(fā)現(xiàn)ng做了一次負(fù)載均衡，而且服務(wù)器地址配置的是公網(wǎng)ip，猜測可能是這個問題，死馬當(dāng)成活馬醫(yī)，隨便試試看。修改為內(nèi)網(wǎng)地址，然后重啟ng后驗(yàn)證發(fā)現(xiàn)正常了。就這樣正常了?；舜蟀胩鞎r間，總算解決了。后來復(fù)盤討論猜測，應(yīng)該是ng接收到文件后，通過負(fù)載均衡走公網(wǎng)ip轉(zhuǎn)了一圈回來導(dǎo)致Waiting for server respnse 耗時過長。

一不小心就有坑。

總結(jié)

到此這篇關(guān)于Waiting for server respnse耗時過長原因排查及解決的文章就介紹到這了,更多相關(guān)Waiting for server respnse耗時過長內(nèi)容請搜索腳本之家以前的文章或繼續(xù)瀏覽下面的相關(guān)文章希望大家以后多多支持腳本之家！