How to analyze ST12 ABAP trace to tune SAP program performance | SAP application performa...

Pgina 1 de 8

SAP application performance

SAP DEVELOPMENT, SAP SUPPORT

HOW TO ANALYZE ST12 ABAP TRACE TO TUNE

SAP PROGRAM PERFORMANCE
GALLERY | AUGUST 31, 2012 | ERIC | 2 COMMENTS

Stop Missing IT Alerts

Fix Issues Before Customers Notice. Happy Engineers. Happier Customers.

You are asked to work on a SAP ABAP program to make it run faster. You are following the
performance process discussed in the post SAP ABAP program performance tuning process. You
have used SAP ST12 transaction to trace program execution. Now you are wondering how to
understand SAP ST12 traces collected and do the performance analysis to find out specific
performance tuning opportunity. This post would cover:

1. How to understand ABAP trace of ST12 and

2. How to analyze ABAP trace for performance tuning.

SQL trace of ST12 would be discussed in separate post.

1 Understand data in SAP ST12 ABAP trace screen

Again, here I assume that you know how to navigate through ST12 trace. SAP ST12 has following
evaluation options

Figure 1 ST12 traces

ST12 trace analysis has two main components normally: ABAP trace and performance(SQL) trace
.

http://www.sap-perf.ca/sap-st12-program-performance-improvemen/ 29/09/2016
How to analyze ST12 ABAP trace to tune SAP program performance | SAP application performa... Pgina 2 de 8

Click ABA Trace button, you would get ST12 ABAP trace screen like:

Figure 2 ABAP trace screen

The above screen has two parts vertically the upper part is overview of runtime distribution. The time
distribution tell you program runtime distribution among CPU(ABAP), Database and system. In the
figure-2, The program spends 62% of runtime on ABAP operation. The lower part is a hit list showing
runtime distribution among ABAP components. Hit list is sorted on gross time by default. But you can
sort it on other column based on your analysis need.

Now you wonder what are those columns Call etc in SAP ST12 ABAP trace screen meaning. Please
refer to table 1 for details:

Table 1 Understand ST12 ABAP trace data

Column Explanation

Call Specific operation executed captured in the trace can be a simple ABAP
statement or a form/FM etc.

No. number of times which the object in call column is actually executed during
the trace.

Gross total time which call takes to execute No. times.

Net time spent by direct ABAP/SQL statements in object under call column. For
simple ABAP statement Gross = Net. for a function module, Net time is
a sum of time spent by all direct/simple ABAP/SQL statements in object
under call column.

http://www.sap-perf.ca/sap-st12-program-performance-improvemen/ 29/09/2016
How to analyze ST12 ABAP trace to tune SAP program performance | SAP application performa... Pgina 3 de 8

Gross(%) Gross/total-runtime X 100%.

Net(%) Net/total-runtime X 100%.

Program Where the call is from.

Type Default blank Call is an ABAP operation.

DB call is aSQL operation.

SYS call is a system operation.

2 Analyze ABAP trace

2.1 Identify silver bullet from ST12 ABAP trace

In my experience, performance issues are often caused by top expensive ABAP statements in the
program. Addressing those individual ABAP statements usually improve a program performance
greatly resulting in meeting business performance requirement. Those top expensive ABAP statements
are what I called silver bullet.

If you sort SAP ST12 ABAP trace screen by Net % column descending, then most expensive
ABAP/SQL statements would show up at top of display like below:

Figure 3 ST12 ABAP trace sorted by Net%

To review corresponding ABAP source code detail, you can place the cursor on the line, then click
icon in SAP ST12 ABAP trace screen. For example, I click once on 2nd line -Select LIPS, then I click .
It shows program name, exact source code info as below

http://www.sap-perf.ca/sap-st12-program-performance-improvemen/ 29/09/2016
How to analyze ST12 ABAP trace to tune SAP program performance | SAP application performa... Pgina 4 de 8

Figure 4 Sample Source code related to ABAP trace

If you have ABAP knowledge, you can understand why the statement is so expensive in its context, like
sort a unchanged table in a loop etc. Application knowledge with insight on testing case can help you to
identify problem and solution quickly, For example, if the testing case is to create one sale order, but
top expensive ABAP statement is to read order header table VBAK many times, then this is definitely a
design or coding issue.

For DB type of call, it would show corresponding SQL summary screen for that location if you click on
the link . See following example for Call Select LIPS.

On the above screen, you would find important information like program, location, number of
execution, number of records etc needed in performance analysis. You also can get SQL execution plan
from here. I would cover more in SQL analysis of SAP ST12 trace.

Following is a list of common scenarios on expensive ABAP statement from my experiences:

Table 2 Typical ABAP performance concerns and their solution

Item Likely solution Comment

Wrong technique to read internal Sort, binary read, using table index. How to read a table would
table make material difference for
a big internal table.

Too many read on internal table Combine multiple read statements. Reduce un-necessary visit on
from different places the same table.

http://www.sap-perf.ca/sap-st12-program-performance-improvemen/ 29/09/2016
How to analyze ST12 ABAP trace to tune SAP program performance | SAP application performa... Pgina 5 de 8

Sort a table repeatedly Avoid un-necessary sort. Sorting a table in a loop or

sorting the same table at
different locations is an
enemy for performance.

Too many individual operation on Use mass operation related to internal

internal table like modification etc table.

Loop on internal table Reduce loop, combine loop etc

Expensive SQLs Reduce # of execution, use right index, More details in ST12 SQL
buffer table/data etc. trace analysis section.

Others like sleep, wait event Avoid synchronous RFC calls and hard
coded wait and sleep etc.

RFC Tuning remote executed FM/program.

I would like to point out no matter how efficient a code is, it should not be executed if it is not needed
by business. So we should try to avoid executing the code instead of improving the code in such
situation. This has been covered below as a separate point for subroutine/form but the idea is
applicable here as well.

2.2 Identify extra subroutine call based on ST12 ABAP trace

Hopefully, by addressing expensive ABAP statements, the program performance meets requirement. If
there is no silver bullet detected in ST12 ABAP trace and program performance is short of
expectation, what we should do next?

Now, we should pay attention to ABAP subroutines (forms and Function module) calls, we should
consider following points

Whether the program needs to execute the subroutine.

Whether number of times which the subroutine is executed by the program is justified by
business/functional need.

I think you remember our focus is top expensive subroutine calls in this type of analysis.

http://www.sap-perf.ca/sap-st12-program-performance-improvemen/ 29/09/2016
How to analyze ST12 ABAP trace to tune SAP program performance | SAP application performa... Pgina 6 de 8

Figure 5 ABAP trace validate number of execution

You need application-level knowledge to assess above points. If one function module takes 60 minutes
for two executions, it might reduce runtime 30 minutes when number of execution is one. If we remove
the function call, it would save 60 minutes.

In my performance tuning experience, I found that a logic/subroutine developed for one country was
executed un-necessary in another countrys business process, this contributed to performance issue.
In another scenario, I found a logic which should be executed once on SAP document head level was
executed at line item level this means if the logic would execute 100 times if the document has 100
line items even the logic only need to execute once for the whole document.

You can use Call Hierarchy button to do top down analysis to see where time is spent or bottom-up to
see where the call is from. You might find this useful. But I seldom find the need to do this type of
analysis.

After all above works (including SQL analysis), performance of the program is normally greatly
improved and meets users expectation. However there are cases that we cannot meet performance
tuning goal and no more meaningful tuning opportunity with all above effort. Then what? Please
continue reading.

2.3 Review Program Design and Configuration

Now you can analyze general performance and try to find out what you should do to improve the
performance.

You can open ABAP trace summary screen to get an overview of performance on the program
execution by clicking ABAP Trace Summary button. This would show runtime distribution of program
execution. The relation among them is total runtime = database time + ABAP time + system time. Total
runtime showed up in ST12 should be almost similar to actual program runtime. If there are big
difference between ST total time and actual program runtime, this can be related to setting of ST12
when you did the trace and operating system and the quality of trace might be jeopardized. You might
wish to redo the trace.

http://www.sap-perf.ca/sap-st12-program-performance-improvemen/ 29/09/2016
How to analyze ST12 ABAP trace to tune SAP program performance | SAP application performa... Pgina 7 de 8

Please be advised this CPU time is actually the time which the program spends in ABAP logic side which
can includes wait time not the actual CPU time which the server spends during the program
execution.

System time should be minimal normally under 1%. If this is high, then you need to review system
status. You might need to redo the trace when the system is in normal load status.

There are other views like Summary per application component etc.

With overview information from ST12 ABAP summary screen and top expensive subroutine
information from ST12 ABAP trace screen, you should be able to establish function area which creates
the performance bottleneck. At this point, we need to review program design and underlying function
configuration to make performance improvement. Our customer order loading program performance
was greatly improved after SAP SD price procedure is simplified such as reducing number of price
group and optimizing access sequence via pre-step etc.

Performance issue can be due to overall solution design. In one case, I was asked to approve index
request for a local report which mainly produces supply/demand picture for selected materials, It took
10 minutes to give the picture for a single material. To fix this, developer planned to create two indexes
on two different SAP tables. In my experience, I know that this local report is similar to standard MM
transaction MD04 which takes seconds to return similar result. That information is shared with
developer. The program was leveraged related logic from standard SAP MD04 design and performance
issue was addressed without creating new indexes.

Coming to this point, the program should be able to meet performance requirement in most cases.
However, if performance of transaction still falls short of expectation due to volume, what is next step
to make program to meet the performance requirement.

http://www.sap-perf.ca/sap-st12-program-performance-improvemen/ 29/09/2016
How to analyze ST12 ABAP trace to tune SAP program performance | SAP application performa... Pgina 8 de 8

2.4 Break-down the job and Use parallel processing

After all those effort , if the performance is still a concern, there is no ABAP/SQL coding issue, 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. I
would write a post about parallel processing in the future.

2.2 SQL Trace Review

This is to fix inefficient database access based on SQL Summary screen from SAP ST12 performance
trace, following is SQL summary screen

If performance trace shows that program spends most of time on database side, it is critical to analyze
program performance/SQL trace to identify improvement opportunity. Please Click here for my
subsequent post on how to analyze SAP ST12 SQL trace to tune SAP program performance.

SAP PROGRAM PERFORMANCE TUNING;SAP PROGRAM PERFORMANCE ANALYSIS;SAP ST12 ABAP TRACE; HOW TO IMPROVE SAP
PROGRAM PERFORMANCE;

2 THOUGHTS ON HOW TO ANALYZE ST12 ABAP TRACE TO TUNE SAP PROGRAM

PERFORMANCE

idhasoft563
OCTOBER 17, 2014 AT 11:21 PM

Hi, Thanks for posting such a nice topic on SAP Programming.

http://www.idhasoft.com/sap/

Pingback: Performance analysis on standard SAP program SHP_DELIVERY_COMPLETE | sap-perf.ca

http://www.sap-perf.ca/sap-st12-program-performance-improvemen/ 29/09/2016