资讯专栏INFORMATION COLUMN

记一次线上接口请求慢问题分析

IT那活儿 / 869人阅读
记一次线上接口请求慢问题分析
最近发现线上系统有个页面访问非常缓慢,页面打开需要20S左右,抽空优化了一下,顺便记录一下分析过程。
首先在慢页面打开F12,查看访问慢的请求如下图,请求地址为:/modelManage/overviewPage/getDrillDownList,目前的接口请求时间为17.6S。

通常来说,当我们发现应用的某个接口响应比较慢,这时候想要找到代码中耗时的部分,比较容易想到的是在接口链路的IO操作上下游打印时间日志,再根据几个时间点的日志算出耗时长的IO操作。
使用这种方式,加日志需要发布,既繁琐又低效。这里就用阿里巴巴开源的 Java 诊断工具 Arthas来分析下,除了分析耗时,还可以打印调用栈、方法入参及返回,类加载情况,线程池状态,系统参数等。其实现原理是解析JVM在操作系统中的文件,大部分操作是只读的,对服务进程没有侵入性。
首先,启动arthas。
在出现的列表中选择要跟踪的服务进程,看到如下界面说明attach成功。
使用sc命令找到待分析的Controller类完整的路径和名称。根据请求地址/modelManage/overviewPage匹配到对应Controller。
使用sm命令查询类的方法信息,根据请求名getDrillDownList匹配到Controller具体方法。
拿到Controller类地址和方法名后,通过trace命令查看整个调用链路上的调用时间,观察到方法内调用service方法占用了大部分时间。
继续trace该service方法的调用链路,观察到mapper部分占用了大部分耗时。
由于mapper部分是对数据库的操作,于是怀疑sql性能有问题,找研发拿到该sql语句。
将该语句直接放到pl/sql执行,用时8.9S,确认是sql执行慢,由于涉及分页需要查询count(*)总条数,所以该语句执行了2次,时间刚好耗时18S左右,问题确定。
简单分析下该sql,结构并不复杂,只针对单表进行查询,表数据量有830多万。
作为开发人员,先简单利用PL/SQL Developer的执行计划评估SQL语句的性能。这里看到的执行计划,只是SQL运行前可能的执行方式,实际运行时可能因为软硬件环境的不同而有所改变,而且cost高的执行计划,不一定在实际运行起来,速度就一定差,我们这里只做一个参考。这里观察到该sql的where条件走了全表扫描,占用了大部分耗费时间。
查看该表针对条件中oper_date字段以及to_char(oper_date)都建了索引,而SQL中却并未使用上该索引。分析SQL语句发现,针对oper_date字段做了多次类型转换,导致了索引失效。
尝试将该条件的强制类型转换替换为其他方式,再次查看执行计划,发现已经可以走索引了,执行耗时问题也消失了。
将该问题反馈给研发优化,优化完成后该请求访问时间降到毫秒级别,页面体验感提升明显,问题解决。


END


更多精彩干货分享

点击下方名片关注

IT那活儿

文章版权归作者所有,未经允许请勿转载,若此文章存在违规行为,您可以联系管理员删除。

转载请注明本文地址:https://www.ucloud.cn/yun/129910.html

相关文章

  • 记一线上频繁FGC的事件和解决方式

    摘要:直接显示了一个疑似内存泄漏的问题。然后分析文件给出的信息,发现一个叫的类。文件里面说的内存泄漏的大概的意思就是说,这个类里面的存放的东西太多了,爆掉了。修改了代码将调用的地方改成了单例。修改完线上跑了一段日子,后来也没有出现过这样的问题。 问题描述:     早上去公司上班,突然就邮件一直报警,接口报异常,然后去查服务器的运行情况,发现java的cpu爆了.接着就开始排查问题 问题解决...

    Alliot 评论0 收藏0
  • 记一线上bug处理-mybatis一级缓存引起

    摘要:问题线上定时任务计算出的金额不对定位问题查看日志好像也执行了但是金额为什么和数据库的表里的不一致再查整个的定时任务日志日切日期 问题: 线上riskProvision定时任务,计算出的金额不对 定位问题: 查看日志 4.13 riskProvision 2017-04-13 01:10:00.009 [org.springframework.scheduling.quartz....

    sean 评论0 收藏0
  • 线上问题排查所引发的思考

    摘要:直到有一天你会碰到线上奇奇怪怪的问题,如线程执行一个任务迟迟没有返回,应用假死。正好这次借助之前的一次生产问题来聊聊如何排查和解决问题。本地模拟上文介绍的是线程相关问题,现在来分析下内存的问题。尽可能的减少多线程竞争锁。 showImg(https://segmentfault.com/img/remote/1460000015568421?w=2048&h=1150); 前言 之前或...

    levy9527 评论0 收藏0
  • 线上问题的排查解决过程

    摘要:排查异常日志,发现没有该问题存在。测试功能正常,没有重现线上问题。解决问题原因定位好了,剩下的就是如何解决了。两个方案修改线上配置该上实施难度系数高,因为公司使用的统一发布部署平台,开发人员无服务器操作权限。 问题 XX系统中,一个用户需要维护的项目数过多,填写的任务数超多,产生了一次工时保存中,只有前面一部分的xx数据持久化到数据库,后面的数据没有保存。 图1 showImg(htt...

    宋华 评论0 收藏0

发表评论

0条评论

IT那活儿

|高级讲师

TA的文章

阅读更多
最新活动
阅读需要支付1元查看
<