大家可能都用過APM監(jiān)控，包括開源的Skywalking、商用的卓豪（ZOHO）ManageEngine APM應(yīng)用性能監(jiān)控、以及云監(jiān)控產(chǎn)品如聽云（Server監(jiān)控），這些APM監(jiān)控產(chǎn)品大大方便了我們實時監(jiān)控應(yīng)用性能，并實現(xiàn)性能深度透視監(jiān)控。

但是這些監(jiān)控手段離真正能夠定位性能問題還是有一段距離，有時候可能就差這最后1米的距離，只能找資深開發(fā)人員介入定位分析，有些開發(fā)人員還真沒這水平。但其實我們用好了工具，任何人都可以參與定位分析，甚至不用依賴開發(fā)人員就能找到問題所在，換句話說，測試人員不需要去深度定位分析問題，但至少要找到和開發(fā)人員溝通的橋梁吧，你把APM監(jiān)控的結(jié)果發(fā)給開發(fā)人員，直接做個甩手掌柜，你信不信，開發(fā)人員可能看都不看，直接說那不是他的代碼問題，可能是環(huán)境或配置問題，因為確實可能真不是他的問題，再說了，你會用APM監(jiān)控工具，開發(fā)人員不一樣會用，用的比你還溜，靠工具不是真本事，會用好工具才是真本事（同時你還能結(jié)合業(yè)務(wù)去思考和應(yīng)用，這是開發(fā)人員不具備的）。?

一、APM監(jiān)控可以告訴你慢的方法名

說到web響應(yīng)慢，有很多方法能夠監(jiān)控，比如我們用瀏覽器自帶的開發(fā)者工具就行，像谷歌瀏覽器通過F12，查看network就能看響應(yīng)時間，就拿我最近測試的一個系統(tǒng)當中的導(dǎo)出功能來實驗：

可以看到導(dǎo)出的請求，響應(yīng)時間12.4秒，大部分時間花在等待服務(wù)器響應(yīng)，這時候我們會說這個接口請求很慢，但我們無法知道慢的方法名，因為我們最多就捕獲到了請求接口：

通過性能測試工具如JMeter，也一樣的道理，我們只知道哪個請求哪個接口慢，不知道哪個方法調(diào)用慢，但通過APM監(jiān)控就可以知道這個請求較慢的方法，包括類名和方法名：

通過APM監(jiān)控的慢事務(wù)分解，我們能看到類名是com.nfschina.controller.ExportController，其調(diào)用方法是exportLoophole

二、APM監(jiān)控無法看到多層次的調(diào)用邏輯

看到了入口方法，我們肯定想知道下一層的方法是什么，想進一步深度探索，這在大部分的APM監(jiān)控是做不到了，比如我們就看事務(wù)的慢組件分解，如下所示：

這個表能看出com.nfschina.controller.ExportController的方法多層調(diào)用嗎？什么也看不出來，只是列出了方法調(diào)用的第一層方法鏈，ExportController為什么慢，還是根本不知道，不過這里還是能排除慢SQL問題（通過PreparedStatement/execute執(zhí)行時間），至于代碼為什么慢的問題是看不出來的，因為這只是第一層代碼調(diào)用關(guān)系。

三、利用Arthas進行深度追蹤

雖然我們作測試時，不能直接定位到性能慢的原因，但至少可以給開發(fā)人員提供慢事務(wù)的方法名，以及平均響應(yīng)時間數(shù)據(jù)，本身也是價值很大。開發(fā)得到這些數(shù)據(jù)，就可以進一步定位分析。同樣我們測試人員也可以嘗試用開發(fā)的工具去進一步定位分析，比如Arthas：

?如上圖，我們第一步，通過 trace?com.nfschina.controller.ExportController exportLoophole追蹤到了慢的方法為com.github.liaochong.myexecl.core.ExcelBuilder下的build，到這里就可以判斷出慢的組件是myexcel，我們再一步步深入追蹤：

最后我們追蹤到是myexcel組件的createRow方法慢（響應(yīng)時間占99.73%），其實就是mysql的數(shù)據(jù)導(dǎo)出后創(chuàng)建excel的table行數(shù)據(jù)很慢。

四、利用Arthas進一步獲取異常信息

APM監(jiān)控除了能捕獲慢事務(wù)方法，還可以捕獲異常信息的方法，如下所示：

通過監(jiān)控，我們可以看出錯誤方法的名稱及傳參，并且拋出的異常信息是CustomException，如果我們覺得不夠清晰，其實我們還可以用Arthas進一步查看和追蹤異常信息，如下：

其實這只是個思路，因為Java的異常信息可能也是一層層上拋的，所以通過Arthas的命令是可以一層層的去追蹤報錯信息。

五、Arthas并不是萬能的

通過上面的例子，你可能會覺得用Arthas定位Java性能問題簡直無所不能，其實不是，引起Java性能問題的因素千種萬種，可能就不是你說的那一種，有些問題不是Java代碼的問題，但也可能會映射成是Java的代碼問題，因為軟件架構(gòu)各式各樣，代碼之間互相調(diào)來調(diào)去，再加上環(huán)境千差萬別，各種因素互相干擾，所以你還要有足夠的敏銳度和經(jīng)驗去排查，以下我拿上面報異常的方法做個例子，這個方法之所以報異常，其實是和性能不穩(wěn)定也有關(guān)，有時候響應(yīng)很快，不到300ms，有時候很慢，高于15s，甚至直接報異常了。我們通過arthas反復(fù)一層層trace，去找到慢的原因：

1、首先我通過APM監(jiān)控獲取它的慢方法名

?2、然后開始arthas追蹤獲取下一層慢方法

?3、繼續(xù)一層層往下追蹤

從上圖可以看出，我們trace的時候，發(fā)現(xiàn)不是每次響應(yīng)時間都很慢的，在同一層trace時，我們是多執(zhí)行一兩遍系統(tǒng)功能操作，才trace到慢的情況，說明這個功能屬于性能不穩(wěn)定。?

4、不要一味的窮盡trace

當我們trace到這一步是，發(fā)現(xiàn)好像跟IO讀取有關(guān)了，如下所示：

這時候我們就要思考了，這個業(yè)務(wù)是屬于IO占用高的事務(wù)嗎？顯然不是呀，這只是個通過漏洞CVE編碼去官網(wǎng)獲取漏洞詳情事務(wù)的請求，請求和獲取的數(shù)據(jù)量都很小，也不需要去查詢SQL。這時候我們就要排除是否Java代碼的問題，因為不排除的話，這樣一直trace下去就會越來越迷茫，因為都超出正常業(yè)務(wù)代碼的范圍了。另外就算是IO問題或網(wǎng)絡(luò)問題，這也要涉及到和其他監(jiān)控工具結(jié)合監(jiān)控，比如通過查看服務(wù)器找找哪個進程線程占用IO高，總之，思路也得轉(zhuǎn)變了。

基于我對這個業(yè)務(wù)的了解，我判斷不太可能是簡單的IO問題，我們首先思考這個方法除了Java代碼本身，還有沒有調(diào)用第三方的東西。通過從開發(fā)那了解到，這個業(yè)務(wù)其實是調(diào)用一個工具去第三方的網(wǎng)站爬取數(shù)據(jù)，這個工具是用go語言寫的，和Java沒關(guān)。所以我們花大把時間在這用arthas去追蹤Java的性能問題，根本是在浪費時間。以上只是舉個例子，就是告訴我們無論什么時候，都要有獨立的判斷能力，不能沉浸于工具帶給我們的方便，而放棄了思考。

既然，找到了是這個go語言寫的小工具的性能問題，那我們就直接調(diào)用和測試這個小工具，拋開Java的干擾，同時優(yōu)化性能也可以從Java語言轉(zhuǎn)移到這個golang小工具了，以下是通過JMeter對這個小工具的測試報告（單用戶測試），發(fā)現(xiàn)確實是性能不穩(wěn)定：

?響應(yīng)時間波動非常大：

在單用戶下，性能就如此不穩(wěn)定，由于這個golang小工具，還會到漏洞官網(wǎng)去爬取數(shù)據(jù)，所以我們直接用JMeter按同樣的調(diào)用邏輯去官網(wǎng)爬取數(shù)據(jù)（繞開這個工具），看看對方的網(wǎng)站性能如何：

性能很高，兩個接口加起來平均也不到200ms，再看響應(yīng)時間波動和網(wǎng)絡(luò)流量，都不大（響應(yīng)時間有較大抖動，但最大響應(yīng)時間都不高），如下所示：

說明，golang小工具爬取數(shù)據(jù)的性能很不穩(wěn)定，不是和網(wǎng)站頁面請求及網(wǎng)絡(luò)性能有關(guān)，是它自身的性能問題（當然是否觸發(fā)防爬取也需要考慮），通過排除法也可以告知開發(fā)人員，應(yīng)該好好對這個golang寫的小工具進行性能定位分析，由于本篇講的是APM監(jiān)控+Arthas定位分析問題，至于定位分析golang就需要用到別的工具，如pprof，本篇就不繼續(xù)展開說明了（注：這個性能問題最后發(fā)現(xiàn)主要是由https證書驗證引起，開發(fā)的臨時解決方案是請求https時跳過證書驗證）。文章來源地址http://www.zghlxwxcb.cn/news/detail-633610.html

到了這里，關(guān)于利用Arthas+APM監(jiān)控進行Java性能深度定位的文章就介紹完了。如果您還想了解更多內(nèi)容，請在右上角搜索TOY模板網(wǎng)以前的文章或繼續(xù)瀏覽下面的相關(guān)文章，希望大家以后多多支持TOY模板網(wǎng)！