線上服務平均響應時間太長,怎么排查?
https://xie.infoq.cn/article/914b5c56000a3880016abd8d6
前言:
最近線上環境某個接口服務響應時間偏長,導致用戶體驗超差,那平時該怎么快速的排查這類問題呢?①、為代碼添加上詳細的打印日志;不建議 ,一是線上環境,沒法隨便的重新部署更換了詳細日志的代碼,二是 添加詳細的日志輸出,那就意味這會生成大量的日志文件,這些日志文件會占據大量服務器磁盤空間。②、搭建一個模擬了線上環境的測試環境進行復盤排查;額,出現了這種問題哪有那么多的時間讓你進行環境復盤排查,所以此方案也是 不建議的 。③、線上診斷神器 Arthas ,這個工具是阿里開源的,專門用于線上環境問題排查的,這個工具提供了很多 的 命令 用來排查問題;當出現上面的響應時間偏長的問題,就可以使用 Arthas 提供的 trace 命令進行排查,使用這個工具的 trace 命令可以統計到方法中整個調用鏈路上的所有性能開銷和追蹤調用鏈路,查找其中耗時比較長的方法再具體排查即可。
文章接下來將從兩方面展開:①、搭建模擬線上服務接口響應時間偏長的環境;SpringBoot 服務接口 + JMeter 模擬服務接口調用;②、使用診斷神器 Arthas 提供的命令 trace 命令進行響應時間偏長的問題排查;模擬線上環境:1、SpringBoot 項目搭建,并且編寫好服務接口;
注意:服務接口代碼為了簡便,只寫了 一些大循環的代碼 來模擬較長的耗時;除此之外,實際上還包含很多多其它常見的情況,例如:①、服務接口方法中存在很多的 JDBC 操作 ,并且由于數據庫中數據量太大,導致很多的 JDBC 查詢非常耗時,并且此時可能由于還沒有創建合適的索引,導致查詢耗時更加的長,最終導致服務接口響應時間偏長;②、此服務接口中調用了 其它的服務接口 ,由于內部調用的其它服務接口出現問題等,導致此其它服務接口執行耗時比較長,進而導致服務接口響應時間偏長;
服務接口代碼如下:
test1、test2方法如下:
2、JMeter 模擬用戶調用的測試腳本配置:
3、服務接口 SpringBoot 代碼 和 JMeter 測試腳本的所在項目位置:
服務接口代碼準備好后,使用IDEA開發工具將其導出為 Jar 包 。?
為了模擬最為真實的線上環境,需將準備好的 服務接口 Jar 包放到 服務器中,然后使用命令 java -jar *.jar 運行起 Jar 包;然后使用 JMeter 進行接口的調用,在 聚合報告 中發現平均響應時間偏長;如圖:
如果有用戶反映某功能響應時間太長了,別著急,根據下面的方法進行排查,絕對方便又快速的找到問題原因。Arthas 問題排查:1、首先需要下載阿里開源的Arthas 的診斷工具 Jar 包,下載地址:arthas-boot.jar ;然后將 Jar 包放到 部署服務接口項目的服務器中 。2、然后使用 ps 命令,查詢出當前運行服務接口的程序進程號;例如:本文章模擬的服務接口程序 Jar 包名稱為 springboot_arthas-1.0.0.jar ,所以命令為:ps -ef | grep springboot_arthas-1.0.0 。3、然后運行Arthas 診斷工具,命令:java -jar arthas-boot.jar ;開始運行的界面如圖:
此時診斷工具還沒有運行完,需要手動選擇要診斷/監控的java 進程,并且此工具也會列出全部的java進程號,你只需要輸入 它們最前的序號 [1] 即可;如圖:
4、運行完后,可以使用 trace命令 監控服務接口方法中調用的其它方法的耗時;trace 命令能主動搜索 class-pattern/method-pattern 對應的方法調用路徑,渲染和統計整個調用鏈路上的所有性能開銷和追蹤調用鏈路。具體命令格式:trace [全限定類名][類中的方法名] 例如:監控本服務接口;com.lyl.controller.TestController : 全限定類名,process:TestController 類中的方法;具體命令:trace com.lyl.controller.TestController process 5、trace 命令執行結果展示,如圖:
通過trace 命令監控統計的調用鏈路各個方法的執行耗時,可以發現調用的 com.lyl.util.StringUtil 類中的 test2() 方法執行耗時比較大;所以需要特別去查看這個方法的代碼是否存在問題;如果這個代碼中還存在許多的方法調用鏈路,則需要再次使用 trace 命令進行監控調用鏈路的耗時,找出具體可能存在問題的方法。
Arthas 阿里開源的診斷工具還提供了很多的命令供使用,大家可以去查看學習,地址:命令列表 。
注意:①、使用Arthas 診斷的程序代碼,在打包時 不能混淆 ,否則在使用trace 命令會報 類或方法找不到 ;②、在使用trace命令監控統計時,需要JMeter測試腳本正在運行調用服務接口,如果沒有調用,則統計不到內部調用鏈路的耗時情況;
能力有限,只能整理這么多,有不對的地方歡迎指出,討論