以下文章来源于ABAP老白,作者ABAP老白
声明:本文仅代表原作者观点,仅用于ERP行业应用和交流,不代表任何公司
昨天是周六,同事给我电话,说有个报工接口出问题了,一般一两秒就执行完的接口,偶尔要几十秒在才能执行完,因为报工会锁定工单,已经影响到生产,请求支援。
登录系统看了一下接口平台,果然接口有问题,一般执行3秒钟左右的接口,很多都要30多秒钟了
这个接口不是我做的,除了知道是一个报工接口,其他一概不知道,现看代码理清逻辑肯定是来不及了,需要以一个最快速的方案来解决掉问题。
既然是正在使用的接口,那么先跟踪一下看看哪个地方卡吧。
先使用事务码:SAT,抓一下运行分析:
非常顺利的抓到了一些运行缓慢的接口调用
打开看看到底是哪儿慢
原来是SQL问题,看样子像是FOR ALL ENTRIES IN的锅啊,定位代码看看
果然是FOR ALL ENTRIES IN,大概率是所用内表component_table为空,或者是内表数据量太大,导致取数太多。
这个时候可以使用外部断点跟踪一下到底是哪个原因,但是因为component_table是函数的一个参数,所以最好的办法是直接使用ZILOG记录下,然后看日志就行了。
给函数添加ZILOG功能:
OK,现在就可以蹲一个执行慢的来分析了。
很快就蹲到了一个:
双击看看参数的值:
内表果然是空的,那问题就确定了,空内表导致FOR ALL ENTRIES的问题,解决方法很简单,加上判断就行了
修改完毕,再跟踪一下看看性能:
哦了,问题解决!
版权归原作者所有,如有侵权请联系删除。
免责声明:本文所用视频、图片、文字如涉及作品版权问题,请第一时间告知,我们将根据您提供的证明材料确认版权并按国家标准支付稿酬或立即删除内容!本文内容为原作者观点,并不代表本公众号赞同其观点和对其真实性负责。