大家可能都用过APM监控，包括开源的Skywalking、商用的卓豪（ZOHO）ManageEngine 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，本篇就不继续展开说明了（注：这个性能问题最后发现主要是由https证书验证引起，开发的临时解决方案是请求https时跳过证书验证）。