一
前言
当程序相对复杂时, 前期开发可能更注重于功能的实现. 等功能实现后, 发现大量数据执行时程序耗时太长. 需要开启程序的优化过程
本文主要介绍程序分析及优化的过程,方法
二
程序性能分析
事务代码ST12 ,选择current mode ,输入程序或事务代码, 点击执行按钮,正常执行程序. 可以在comment中输入一些备注. 以便说明本次跟踪的缘由.
正常执行完程序,退出程序返回到ST12界面, 下方会显示本次执行的日志内容
点击相关的按钮可以看到程序执行过程的所有跟踪信息
ABAP trace中可以看到整体执行的ABAP语句耗时及数据库访问耗时. 下面清单中可以看到每个调用模块的耗时及总耗时占比(cross time in %) 净耗时占比( Net time in % )
一般情况下,通过净耗时占比可以快速定位到耗时较大的模块及语句
三
一个程序的优化
优化前 总用时283秒,大部分开销在表的读取及表的更新上,可以从ABAP 跟踪中看出耗时的SQL语句
01
优化表的读取
关于表的读取优化, 用程序的主动缓存(配置表全表缓存,业务表单记录缓存)取代SELECT SINGLE 语句(即使使用了表的技术设置添加了表或视图的缓存). 因为程序的调用层级比较深, 使用了静态类的全局变量的方法缓存哈希表.
详见链接
无峰,公众号:ABAP 技巧与实战ABAP基础知识 数据读取的缓存
优化效果
总耗时减少了一半以上,部分select 语句耗时大幅减少
02
把特定业务表改成全表缓存
特定表从单记录主动缓存调整为全表主动缓存
有一定的优化效果,调整的表的访问耗时明显减少.
这种方式会增加程序的内存开销,需要综合分析是否启用.
此时发现程序的最大开销在于数据库的更新
03
调整更新模式
分析更新逻辑,调整更新模式,按行更新调整为按单更新(不是所有的程序都能做这种调整, 当前这个程序因为业务逻辑原因, 支持按单更新)
耗时占用减少到原来的1/5左右
另外,数据库更新最好在循环后整体提交(或者达到指定数据量提交,避免每行/每单提交)
四
总结
通过SAP的程序执行分析工具ST12 可以查看程序执行过程中的每个模块/语句的耗时占比 . (其它事务代码如SAT,处理方式和跟踪结果于ST12类似. )
找出占比最高的模块或语句. 找到合适的方法优化.
本文介绍了两个主要优化思路
程序主动缓存表取代系统缓存或数据库访问
按单更新取代明细更新(逻辑允许的情况下).
其它优化思路可以参考之前的部分文章
链接
无峰,公众号:ABAP 技巧与实战SAP小技巧 双LOOP循环的性能优化
链接
Dylan,公众号:ABAP 技巧与实战SAP-ABAP性能优化之构建嵌套结构的哈希表