上海建网站的公司,小企业网站建设的大品牌,慈溪住房和城乡建设部网站,国际新闻快报社大家可能都用过APM监控#xff0c;包括开源的Skywalking、商用的卓豪#xff08;ZOHO#xff09;ManageEngine APM应用性能监控、以及云监控产品如听云#xff08;Server监控#xff09;#xff0c;这些APM监控产品大大方便了我们实时监控应用性能#xff0c;并实现性能…大家可能都用过APM监控包括开源的Skywalking、商用的卓豪ZOHOManageEngine APM应用性能监控、以及云监控产品如听云Server监控这些APM监控产品大大方便了我们实时监控应用性能并实现性能深度透视监控。
但是这些监控手段离真正能够定位性能问题还是有一段距离有时候可能就差这最后1米的距离只能找资深开发人员介入定位分析有些开发人员还真没这水平。但其实我们用好了工具任何人都可以参与定位分析甚至不用依赖开发人员就能找到问题所在换句话说测试人员不需要去深度定位分析问题但至少要找到和开发人员沟通的桥梁吧你把APM监控的结果发给开发人员直接做个甩手掌柜你信不信开发人员可能看都不看直接说那不是他的代码问题可能是环境或配置问题因为确实可能真不是他的问题再说了你会用APM监控工具开发人员不一样会用用的比你还溜靠工具不是真本事会用好工具才是真本事同时你还能结合业务去思考和应用这是开发人员不具备的。
一、APM监控可以告诉你慢的方法名
说到web响应慢有很多方法能够监控比如我们用浏览器自带的开发者工具就行像谷歌浏览器通过F12查看network就能看响应时间就拿我最近测试的一个系统当中的导出功能来实验 可以看到导出的请求响应时间12.4秒大部分时间花在等待服务器响应这时候我们会说这个接口请求很慢但我们无法知道慢的方法名因为我们最多就捕获到了请求接口 通过性能测试工具如JMeter也一样的道理我们只知道哪个请求哪个接口慢不知道哪个方法调用慢但通过APM监控就可以知道这个请求较慢的方法包括类名和方法名 通过APM监控的慢事务分解我们能看到类名是com.nfschina.controller.ExportController其调用方法是exportLoophole
二、APM监控无法看到多层次的调用逻辑
看到了入口方法我们肯定想知道下一层的方法是什么想进一步深度探索这在大部分的APM监控是做不到了比如我们就看事务的慢组件分解如下所示 这个表能看出com.nfschina.controller.ExportController的方法多层调用吗什么也看不出来只是列出了方法调用的第一层方法链ExportController为什么慢还是根本不知道不过这里还是能排除慢SQL问题通过PreparedStatement/execute执行时间至于代码为什么慢的问题是看不出来的因为这只是第一层代码调用关系。
三、利用Arthas进行深度追踪
虽然我们作测试时不能直接定位到性能慢的原因但至少可以给开发人员提供慢事务的方法名以及平均响应时间数据本身也是价值很大。开发得到这些数据就可以进一步定位分析。同样我们测试人员也可以尝试用开发的工具去进一步定位分析比如Arthas 如上图我们第一步通过 trace com.nfschina.controller.ExportController exportLoophole追踪到了慢的方法为com.github.liaochong.myexecl.core.ExcelBuilder下的build到这里就可以判断出慢的组件是myexcel我们再一步步深入追踪 最后我们追踪到是myexcel组件的createRow方法慢响应时间占99.73%其实就是mysql的数据导出后创建excel的table行数据很慢。
四、利用Arthas进一步获取异常信息
APM监控除了能捕获慢事务方法还可以捕获异常信息的方法如下所示 通过监控我们可以看出错误方法的名称及传参并且抛出的异常信息是CustomException如果我们觉得不够清晰其实我们还可以用Arthas进一步查看和追踪异常信息如下 其实这只是个思路因为Java的异常信息可能也是一层层上抛的所以通过Arthas的命令是可以一层层的去追踪报错信息。
五、Arthas并不是万能的
通过上面的例子你可能会觉得用Arthas定位Java性能问题简直无所不能其实不是引起Java性能问题的因素千种万种可能就不是你说的那一种有些问题不是Java代码的问题但也可能会映射成是Java的代码问题因为软件架构各式各样代码之间互相调来调去再加上环境千差万别各种因素互相干扰所以你还要有足够的敏锐度和经验去排查以下我拿上面报异常的方法做个例子这个方法之所以报异常其实是和性能不稳定也有关有时候响应很快不到300ms有时候很慢高于15s甚至直接报异常了。我们通过arthas反复一层层trace去找到慢的原因
1、首先我通过APM监控获取它的慢方法名 2、然后开始arthas追踪获取下一层慢方法 3、继续一层层往下追踪 从上图可以看出我们trace的时候发现不是每次响应时间都很慢的在同一层trace时我们是多执行一两遍系统功能操作才trace到慢的情况说明这个功能属于性能不稳定。
4、不要一味的穷尽trace
当我们trace到这一步是发现好像跟IO读取有关了如下所示 这时候我们就要思考了这个业务是属于IO占用高的事务吗显然不是呀这只是个通过漏洞CVE编码去官网获取漏洞详情事务的请求请求和获取的数据量都很小也不需要去查询SQL。这时候我们就要排除是否Java代码的问题因为不排除的话这样一直trace下去就会越来越迷茫因为都超出正常业务代码的范围了。另外就算是IO问题或网络问题这也要涉及到和其他监控工具结合监控比如通过查看服务器找找哪个进程线程占用IO高总之思路也得转变了。
基于我对这个业务的了解我判断不太可能是简单的IO问题我们首先思考这个方法除了Java代码本身还有没有调用第三方的东西。通过从开发那了解到这个业务其实是调用一个工具去第三方的网站爬取数据这个工具是用go语言写的和Java没关。所以我们花大把时间在这用arthas去追踪Java的性能问题根本是在浪费时间。以上只是举个例子就是告诉我们无论什么时候都要有独立的判断能力不能沉浸于工具带给我们的方便而放弃了思考。
既然找到了是这个go语言写的小工具的性能问题那我们就直接调用和测试这个小工具抛开Java的干扰同时优化性能也可以从Java语言转移到这个golang小工具了以下是通过JMeter对这个小工具的测试报告单用户测试发现确实是性能不稳定 响应时间波动非常大 在单用户下性能就如此不稳定由于这个golang小工具还会到漏洞官网去爬取数据所以我们直接用JMeter按同样的调用逻辑去官网爬取数据绕开这个工具看看对方的网站性能如何 性能很高两个接口加起来平均也不到200ms再看响应时间波动和网络流量都不大响应时间有较大抖动但最大响应时间都不高如下所示 说明golang小工具爬取数据的性能很不稳定不是和网站页面请求及网络性能有关是它自身的性能问题当然是否触发防爬取也需要考虑通过排除法也可以告知开发人员应该好好对这个golang写的小工具进行性能定位分析由于本篇讲的是APM监控Arthas定位分析问题至于定位分析golang就需要用到别的工具如pprof本篇就不继续展开说明了。
