性能文章>记一次接口分析>

记一次接口分析原创

2年前
323857

在偶然中发现一个接口耗时有点慢,用了4秒钟

查询了下,这个接口做的事有点多,即有接口调用,又有很多的查询然后保存,所以单看代码或者时序图的话很难看出

然后用了Arthas的分析了一下这个接口

Arthas官网

启动Arthas后选择要分析的项目,然后使用trace功能,trace的功能是输出方法内部调用路径,并输出方法路径上的每个节点上耗时,很符合我这个场景

trace 命令能主动搜索 class-patternmethod-pattern 对应的方法调用路径,渲染和统计整个调用链路上的所有性能开销和追踪调用链路

开启trace

trace com.*** method

然后再次调用接口

image-20220921173414923

就可以看到这个接口下的调用链和耗时,很快就发现了耗时最高的接口,于是继续trace这个接口,重复以上步骤,最终发现耗时的地方


竟然是两个插入方法耗时最久

看了下表结构也没有很多索引,而且数据量也不大只有几万条,把sql复制到数据库中执行,也是正常的

看了下代码,这两个插入是在循环中的,但是循环只有10多次,在本地测试了一下也是正常的

而且本地的接口总耗时才3537ms

Arthasdashboard看了下项目的资源情况

发现堆快满了,而且只有100多m的内存,看了下启动参数,只给这个项目指定了128m的内存。。

又看了下服务器内存,也快被用完了

然后把这个项目移动资源比较足的服务器,并且把内存扩大到256m

再次调用接口只用了1秒多,可看到资源对项目的影响

点赞收藏
分类:标签:
阿弱
请先登录,查看5条精彩评论吧
快去登录吧,你将获得
  • 浏览更多精彩评论
  • 和开发者讨论交流,共同进步

为你推荐

JDBC PreparedStatement 字段值为null导致TBase带宽飙升的案例分析

JDBC PreparedStatement 字段值为null导致TBase带宽飙升的案例分析

随机一门技术分享之Netty

随机一门技术分享之Netty

MappedByteBuffer VS FileChannel:从内核层面对比两者的性能差异

MappedByteBuffer VS FileChannel:从内核层面对比两者的性能差异

7
5