Tag Archives: SAP ABAP program performance tuning process; ABAP program performance tuning guide; SAP program performance analysis; SAP program performance tuning strategy

SAP ABAP program performance tuning process

You are asked to work on a SAP ABAP program to make it run faster. It is a big program with thousands lines of ABAP source codes, so you are wondering what is starting point and the efficient process to tune the SAP program performance. This is what this post is written for. This post covers:

  1. Overview on SAP ABAP program performance tuning process and
  2. Understand steps in SAP ABAP program performance tuning process.

I am talking about tuning a SAP ABAP program performance due to “persistent” performance issue which is rooted from program code/design here not one time performance incident due to sporadic resource contention in program operating environment.

1 Overview on performance improvement process

Performance improvement is normally an iterative process until performance tuning goal has been met. The overall process is illustrated as what showed in figure 1.

Figure 1 SAP program performance improvement process

SAP ABAP program performance tuning can be an iterative process. When top performance concerns are addressed, other performance concerns which are under shadow of the addressed performance concerns can be surfaced as major improvement opportunity for next cycle. By repeating the cycle, you bring the program performance to a new level until your performance tuning goal is reached.

2 Understand steps in SAP ABAP program performance tuning process

2.1 Understand performance gap

This is the starting point of SAP ABAP program performance tuning process. At this step, you need to find out:

  1. Targeted performance – This helps you to establish performance tuning goal and
  2. Current performance – This helps you to establish performance baseline which can be used to measure the performance improvement.

The difference between targeted performance and current performance is the performance gap which the process is targeted to eliminate.

2.2 Identify performance scenario/test case

 

This is to understand under what condition a program is executed with “poor” performance so performance testing case can be planned. Different business scenario would involve different portions of program code. If performance test case is not related to performance issue, then the “bad” code would not be executed so it would not be captured during trace. So it is critical to performance tuning process that a right performance testing case is identified for each performance scenario.

When performance issue is mainly due to volume, a serial of testing cases with ramp-up volume might need to be defined instead of one testing case with big volume which can run for long time like hours or even days. I normally limit runtime duration for a performance testing case execution under one hour. At the same time, you need to maintain a “meaningful” testing volume so performance issue can appear.

2.3 Execute scenarios with performance tracing

This is to execute performance test case and use performance tool to trace execution of test case. SAP trace can show how much time is spent by a subroutine/function-module/form, an ABAP operation and a SQL operation. So you can find where the time is spent by the program –which helps to locate improvement opportunity in the program code.

There are several SAP performance tracing tools like SAP transaction ST12, ST05 and SE30 etc. I would recommend that we use SAP transaction ST12 to do the trace since it can catch ABAP trace (ABAP logic operation) and performance trace(SQL execution) in one execution. Of course, you can use SAP transaction ST05 if it is a done deal that a program is slow due to database access or SAP transaction SE30 if program is slow due to ABAP logic involving no database operation.

When you do trace, the scenario being traced had better be executed twice one after another and make sure performance trace is turned on for the 2nd execution only – this is to eliminate buffering impact on program performance.

If testing lasts longer, you might want to do several traces at different time during the test execution instead of one trace.

2.4 Analyze trace and identify improvement opportunity

This is to review performance trace to identify major inefficient “ABAP logic” and inefficient SQL operation. Following is the strategy I used to analyze ABAP and SQL traces for ABAP program performance improvement:

Figure 2 ABAP/SQL traces analysis strategy

Inefficient “ABAP logic” would consume application server CPU power. Inefficient ABAP logic is mainly related to internal table handling and loop etc.

Inefficient SQL is putting extra load on database server. Inefficient SQL operation is those SQLs like accessing database table without proper selection criteria etc.

  • Identify silver bullet from performance trace

    This is to review performance trace to identify top expensive ABAP logic/ABAP statement/SQL statements. If performance gap is 20% and performance tracing shows that one ABAP statement takes 40% of running time, then tune the ABAP statement might give you the expected performance gain.

    SAP ST12 traces provide gross time and net time for an operation captured in the trace. I normally sort by “net time” so top expensive ABAP/SQL statement can show on the top – this facilitate analysis.

  • Identify “extra” subroutine call

    No matter how efficient a function is coded – if it is not needed by business, then it should not be executed. So we should try to avoid executing such code instead of improving the code. If one time execution is enough, then it should not be executed for the 2nd time.

  • Review program design and function configuration

    If no enough performance improvement opportunity is identified, then we need to review overall solution design or related SAP configuration to seek performance improvement opportunity.

  • Break down workload and use parallel processing

    After all those effort , if the performance is still a concern, there is no performance concern over the program on ABAP logic and database access, there is no function configuration concern, the design is ideal but performance is still short of the expectation. Now we should consider breaking down the work to smaller tasks which can be handled by multiple processes at the same time – this is called parallel process. Bottom-line is that we should only consider parallel solution when underlying program has a sound design and performance has been well tuned.

In a program, there might a lot of improvement opportunity technically but each improvement opportunity might bring different level of performance improvement to the program. Here, we focus on those improvement opportunities which would bring significant improvement on ABAP program performance.

Following is two sample screens – one is ABAP trace screen and the other is performance/SQL trace screen. Both screens are from the same ST12 tracing on a program execution.

Figure 3 ABAP trace of a program execution

Figure 4 – SQL trace of a program execution

Attention: If your program is interacting with another process executed locally or remotely via RFC( Remote Function Call) and performance trace shows that your program is spending a lot of time in waiting for completion of RFC, then you need to tune the RFC program involved. If the remote executed program is an ABAP program, the same process mentioned here can be applied to tune the RFC program performance.

2.5 Finalize the solution and implement change

This is to take action to implement needed solution to improve the program performance.

2.6 Test and measure performance with the change

This is to repeat testing case again to measure performance improvement with changes.

If testing shows that program performance with the change is still short of expectation, you have to repeat the whole process again.

It is important that we should execute the same test and in the same SAP box before and after the change. Using different testing box is just adding another variable which makes performance measure harder.

SAP transaction SCI known as “SAP Code Inspector” can be used to scan through ABAP code to identify common performance pitfalls like SQL statement without where-clause etc. This is a static performance check. Output from this can be a part of improvement proposal together with what from trace analysis. Static code check is relatively simple and it is not focus of this post. It is a good habit to use SCI to validate change each time after a program is changed as well.

3 Further clarification

There are other performance issues like too much memory used by a program. To tune such performance issue, the overview of process in general is similar to what stated here. But what tools should be used to catch memory offender is different – ST12, SE30 and ST05 would not tell memory usage. I might write another post on how to tune ABAP program memory usage in the future.

Program can suddenly run slower due to many reasons in production box like contention or bug of a system (SAP, OS and database) etc. Program performance at such scenario cannot be improved via the process mentioned here. Solving this type of performance issue normally requests changes on other components of operating environment instead of program itself. I have written a post on how to trouble-shoot production performance incident.

In this post, I have recommended to use SAP ST12 to trace SAP ABAP program execution for performance analysis. You can click here to know how to use ST12 to do performance trace. If you are interested, there are posts on how to analyze SAP ST12 ABAP trace to tune SAP program performance and how to analyze SAP ST12 SQL trace to tune SAP program performance.

You are asked to work on a SAP ABAP program to make it run faster. It is a big program with thousands lines of ABAP source codes, so you are wondering what is starting point and the efficient process to tune the SAP program performance. This is what this post is written for. This post covers:

  1. Overview on SAP ABAP program performance tuning process and
  2. Understand steps in SAP ABAP program performance tuning process.

I am talking about tuning a SAP ABAP program performance due to “persistent” performance issue which is rooted from program code/design here not one time performance incident due to sporadic resource contention in program operating environment.

1 Overview on performance improvement process

Performance improvement is normally an iterative process until performance tuning goal has been met. The overall process is illustrated as what showed in figure 1.

Figure 1 SAP program performance improvement process

SAP ABAP program performance tuning can be an iterative process. When top performance concerns are addressed, other performance concerns which are under shadow of the addressed performance concerns can be surfaced as major improvement opportunity for next cycle. By repeating the cycle, you bring the program performance to a new level until your performance tuning goal is reached.

2 Understand steps in SAP ABAP program performance tuning process

2.1 Understand performance gap

This is the starting point of SAP ABAP program performance tuning process. At this step, you need to find out:

  1. Targeted performance – This helps you to establish performance tuning goal and
  2. Current performance – This helps you to establish performance baseline which can be used to measure the performance improvement.

The difference between targeted performance and current performance is the performance gap which the process is targeted to eliminate.

2.2 Identify performance scenario/test case


This is to understand under what condition a program is executed with “poor” performance so performance testing case can be planned. Different business scenario would involve different portions of program code. If performance test case is not related to performance issue, then the “bad” code would not be executed so it would not be captured during trace. So it is critical to performance tuning process that a right performance testing case is identified for each performance scenario.

When performance issue is mainly due to volume, a serial of testing cases with ramp-up volume might need to be defined instead of one testing case with big volume which can run for long time like hours or even days. I normally limit runtime duration for a performance testing case execution under one hour. At the same time, you need to maintain a “meaningful” testing volume so performance issue can appear.

2.3 Execute scenarios with performance tracing

This is to execute performance test case and use performance tool to trace execution of test case. SAP trace can show how much time is spent by a subroutine/function-module/form, an ABAP operation and a SQL operation. So you can find where the time is spent by the program –which helps to locate improvement opportunity in the program code.

There are several SAP performance tracing tools like SAP transaction ST12, ST05 and SE30 etc. I would recommend that we use SAP transaction ST12 to do the trace since it can catch ABAP trace (ABAP logic operation) and performance trace(SQL execution) in one execution. Of course, you can use SAP transaction ST05 if it is a done deal that a program is slow due to database access or SAP transaction SE30 if program is slow due to ABAP logic involving no database operation.

When you do trace, the scenario being traced had better be executed twice one after another and make sure performance trace is turned on for the 2nd execution only – this is to eliminate buffering impact on program performance.

If testing lasts longer, you might want to do several traces at different time during the test execution instead of one trace.

2.4 Analyze trace and identify improvement opportunity

This is to review performance trace to identify major inefficient “ABAP logic” and inefficient SQL operation. Following is the strategy I used to analyze ABAP and SQL traces for ABAP program performance improvement:

Figure 2 ABAP/SQL traces analysis strategy

Inefficient “ABAP logic” would consume application server CPU power. Inefficient ABAP logic is mainly related to internal table handling and loop etc.

Inefficient SQL is putting extra load on database server. Inefficient SQL operation is those SQLs like accessing database table without proper selection criteria etc.

  • Identify silver bullet from performance trace

    This is to review performance trace to identify top expensive ABAP logic/ABAP statement/SQL statements. If performance gap is 20% and performance tracing shows that one ABAP statement takes 40% of running time, then tune the ABAP statement might give you the expected performance gain.

    SAP ST12 traces provide gross time and net time for an operation captured in the trace. I normally sort by “net time” so top expensive ABAP/SQL statement can show on the top – this facilitate analysis.

  • Identify “extra” subroutine call

    No matter how efficient a function is coded – if it is not needed by business, then it should not be executed. So we should try to avoid executing such code instead of improving the code. If one time execution is enough, then it should not be executed for the 2nd time.

  • Review program design and function configuration

    If no enough performance improvement opportunity is identified, then we need to review overall solution design or related SAP configuration to seek performance improvement opportunity.

  • Break down workload and use parallel processing

    After all those effort , if the performance is still a concern, there is no performance concern over the program on ABAP logic and database access, there is no function configuration concern, the design is ideal but performance is still short of the expectation. Now we should consider breaking down the work to smaller tasks which can be handled by multiple processes at the same time – this is called parallel process. Bottom-line is that we should only consider parallel solution when underlying program has a sound design and performance has been well tuned.

In a program, there might a lot of improvement opportunity technically but each improvement opportunity might bring different level of performance improvement to the program. Here, we focus on those improvement opportunities which would bring significant improvement on ABAP program performance.

Following is two sample screens – one is ABAP trace screen and the other is performance/SQL trace screen. Both screens are from the same ST12 tracing on a program execution.

Figure 3 ABAP trace of a program execution

Figure 4 – SQL trace of a program execution

Attention: If your program is interacting with another process executed locally or remotely via RFC( Remote Function Call) and performance trace shows that your program is spending a lot of time in waiting for completion of RFC, then you need to tune the RFC program involved. If the remote executed program is an ABAP program, the same process mentioned here can be applied to tune the RFC program performance.

2.5 Finalize the solution and implement change

This is to take action to implement needed solution to improve the program performance.

2.6 Test and measure performance with the change

This is to repeat testing case again to measure performance improvement with changes.

If testing shows that program performance with the change is still short of expectation, you have to repeat the whole process again.

It is important that we should execute the same test and in the same SAP box before and after the change. Using different testing box is just adding another variable which makes performance measure harder.

SAP transaction SCI known as “SAP Code Inspector” can be used to scan through ABAP code to identify common performance pitfalls like SQL statement without where-clause etc. This is a static performance check. Output from this can be a part of improvement proposal together with what from trace analysis. Static code check is relatively simple and it is not focus of this post. It is a good habit to use SCI to validate change each time after a program is changed as well.

3 Further clarification

There are other performance issues like too much memory used by a program. To tune such performance issue, the overview of process in general is similar to what stated here. But what tools should be used to catch memory offender is different – ST12, SE30 and ST05 would not tell memory usage. I might write another post on how to tune ABAP program memory usage in the future.

Program can suddenly run slower due to many reasons in production box like contention or bug of a system (SAP, OS and database) etc. Program performance at such scenario cannot be improved via the process mentioned here. Solving this type of performance issue normally requests changes on other components of operating environment instead of program itself. I have written a post on how to trouble-shoot production performance incident.

In this post, I have recommended to use SAP ST12 to trace SAP ABAP program execution for performance analysis. You can click here to know how to use ST12 to do performance trace. If you are interested, there are posts on how to analyze SAP ST12 ABAP trace to tune SAP program performance and how to analyze SAP ST12 SQL trace to tune SAP program performance.