不要慌，上面只是一张贴图。
为什么“慢”那么难查
网站卡顿、页面加载过慢是互联网应用最常见的问题之一。排查、解决这类问题通常会花费开发运维人员大量的时间，通常是因为以下三个原因：
-
应用链路太长，无从下手。
-
从前端页面到后台网关，从Web应用服务器到后台数据库，任何一个环节的问题都有可能导致请求整体卡顿，到底是前端资源加载过慢？还是数据库出了问题？还是新发布的服务端代码有性能问题？出现问题的原因五花八门。
-
采用“微服务”架构的应用，链路更加复杂。不同组件可能由不同的团队、人员分别维护，加剧了问题排查的难度。
-
-
日志不全或质量欠佳，现场缺失。
-
应用日志无疑是排查线上问题的神器，但出现问题的位置往往无法预期，发生了问题通常会发现日志信息不全 -- 我们不可能在每一个有可能出现问题的地方打印日志。
-
“慢”的定义偏主观，“慢”有时候往往也是偶发现象。真正要捕捉到“慢”的那一行代码，我们往往需要记录每一次调用，不放过每一行代码，但这往往代价太大。
-
-
监控不足，出现问题为时已晚。
-
业务发展快、迭代速度更快，会导致业务系统频繁修改接口、增加依赖、代码质量恶化。如果没有一个完善的监控体系，能够对应用的每一个接口的性能进行全自动的监控，对出现问题的调用进行自动的记录，等用户反馈问题再来解决，本身就已经太迟了。
-
使用阿里云ARMS的0埋点技术，1分钟定位“慢”问题
利用阿里云ARMS(应用实时监控-
链接
)的线程剖析、调用链诊断、接口监控等一系列功能，您只需要在您的应用启动脚本中增加几行探针加载逻辑(
链接
)，不需要对您的应用代码做任何改动，即可以让应用中所有“慢”调用无处可逃。
第一步：安装Java探针（如果您的应用托管于EDAS，您甚至可以跳过这一步 - 链接）
-
开通ARMS，并创建应用。
-
下载Java探针包并解压。
-
在Java应用启动脚本中增加 -javaagent:/{user.workspace}/ArmsAgent/arms-bootstrap-1.7.0-SNAPSHOT.jar -Darms.licenseKey=xxx -Darms.appId=xxx (appId和licenseKey根据页面分配的信息填写，详情可看 - 链接 )
-
打开ARMS页面，数据开始上报，验证Java探针安装成功。
第二步：在应用概览中发现“慢”可疑线索。
-
进入ARMS应用拓扑图。在应用概览中我们能够明显地看到今天系统中有“慢SQL”5次。
第三步：浏览并发现“慢接口”
-
点击接口列表，我们能够一眼看到这个应用提供的所有接口以及这个接口的调用次数和耗时，当然，这些接口都是ARMS的探针自动在程序中发现的，无需做任何配置。
-
在这些接口中，“慢”接口会被明显标注出来。我们很明显地发现了可疑的慢接口。
-
选中左侧的调用次数最多的”慢”接口，我们可以从右侧看到这次调用明显是“慢”在数据库的调用上。
第四步：到底“慢在哪一行代码”? 一键定位原因！
-
光看到接口的耗时还不够，我们需要精准定位“慢”到底出现在哪一行代码。
-
点击“接口快照”，可以看到这个接口对应的所有接口的快照，快照是对一次调用的全链路调用的完整记录。ARMS探针将用非常小的性能损耗记录每一次调用所经过的代码及耗时，帮助您精准定位“慢”问题。
-
我们点击某一个调用快照的TraceId，展开即可查看到这次调用具体“慢”在哪一行。从上图中我们可以清晰地看到，在这次耗时705毫秒的调用中，大部分的时间都消耗在了"SELECT * FROM l_employee"这次SQL调用中，这明显是一次全表扫描的操作！
-
到此为止，我们已经明确地发现了系统中的一个慢调用的错误根因。并且有充分的依据来指导我们下一步的代码优化工作。我们还可以回到调用接口列表，再逐一打开列表中其他“慢”的调用，逐一解决，相信在ARMS的帮助下，您的网站从此可以远离卡顿的困扰，给用户提供更加流畅的体验。
第五步：防患于未然 -- 设置告警
-
当然，您可以在ARMS的告警设置中对某一个接口或全部接口设置告警，让页面接口出现卡顿时第一时刻通知到您的运维团队。
快速诊断更多问题
-
当然除了错误以外，网站还会出现后台抛错、页面加载失败、内存泄漏等一系列问题。利用ARMS快速解决更多网站疑难杂症，请继续关注“网站常见问题1分钟定位”系列其他文章。
