The ABAP Runtime Trace (SE30) - Quick and Easy

former_member194613 · ‎2007 Nov 13

Besides the SQL Trace, the ABAP Runtime Analysis or ABAP Trace (transaction SE30) is the most important tool to use, if you want to test the performance of your ABAPprogram. Unfortunately, it can be seen in the forum and other sources that many people have questions about ABAP Trace. This blog will provide you with a quick introduction to ABAP Trace, show you how simple it is to execute, and tell you all you need to know for a basic performance analysis.

1. Using the ABAP Runtime Trace

Using this tool is nearly as straightforward as using the SQL trace (see The SQL Trace (ST05) – Quick and Easy😞

Call the ABAP Runtime Analysis (transaction SE30)
Check the measurement restrictions and change them if necessary. See the recommendations below.
Make sure you have executed the test program at least once, or even better, a few times, to fill the buffers and caches. You will obtain reproducible trace results only through repeated execution. We will neglect the initial costs in our examination.
Execute your test program directly from the ABAP Trace. This is possible for transactions, programs, and function modules.
Switch off the trace.
If a trace file was written, it will appear under ‘Performance Data File’.
Evaluate the results file.

There are several other ways to execute the ABAP Trace, not described under step 4; but they are beyond the scope of this blog, please go to the ABAP Trace documentation for more information on them.

The measurement restriction has three tabs.

First tab: Program (Parts)

Second tab: Statements

Third tab: Duration/Type

It is recommended that you create three measurement variants:

PERF_BY_CALL (default): nothing selected on the first tab, on the statement tab everything selected but not the ‘kernel-level runtime administration’ and not the ‘Internal tables’ read and change operations; on the third tab set aggregation ‘per call position’ and set the maximum file size to 20.000 KB and the maximum runtime to 3.000 sec.
PERF_BY_CALL_ITAB: as above, but on the second tab the internal table read and change operations are switched on.
PERF_NO_AGG: as PERF_BY_CALL, but on the third tab the aggregation is ‘none’.

After the test program has finished (see step 3), navigate back to the start screen of the ABAP Trace, where you will find the latest trace file.

With ‘Other File’ you can get a list of all trace files including previous measurements. Note, however, that the SE30 traces are deleted automatically after 8 days. Also remember that the files are stored per application server, so if you want to see traces of prior measurements, then you need to know on which application server the trace was executed.

This section shows how to execute the ABAP Trace. Executing the trace is quite straightforward and can be performed with little prior knowledge. Interpreting the results requires some experience and is explained in the next sections.

2. Trace Results Overview

When you evaluate the trace you will first see the overview screen.

The most important information on this screen is the total runtime on the backend, i.e. on application server and the database. This is your total optimization potential. Perhaps you already had some expectations or external limits for the total runtime. In general, dialog applications with small objects should be considerably faster than 2 seconds, in order to obtain a total response time of 2 seconds. Larger batch jobs may need much longer. It is your task to interpret whether a runtime is good or bad.

Based on user feedback, we have noticed that the graph seems to attract more attention than the actual figures, and users seem to focus heavily on the percentages and the red or green colors in the diagram. However, the colors carry little information, as the color switches from green to red if the percentage is larger than 50%. And the percentages themselves, of course, always add up to 100%. As a result, if one percentage is larger the other one must be smaller.

System and database may be very small, or even zero, but should not be too large. For system, 10% is already too large, and for the database, 50% is quite large. The argument why database should be considerably larger than ABAP is the following: after the data has been read from the database, some kind of processing should occur on the records, so that a ratio of 20 to 40% for database is desirable. Programs with very special tasks can of course have very special percentage distributions.

The hit list is the only additional information available for traces of aggregation type ‘per call(ing) position’. Fortunately, the hit list offers all you need for a quick and easy performance check.

In this section the overview is explained. This is the total runtime and its distribution over the three categories ABAP, Database and System. From the total time you should be able to conclude whether your program is fast or slow, while the percentages tell you where to begin, if you want to optimize performance.

3. Trace Results Hit List

The hit list summarizes the measurements of execution and processing times into one entry per operation. If the aggregation is ‘per calling position’, then you will see two separate entries for the same operation if the operation is called from two different programs or if the operation is called from two different positions in the same program. The unique keys fields of the hit list are therefore ‘Call’, i.e. operation (col. 7), ‘Program Name’ (col.8) and ‘Line’, i.e. calling position. Unfortunately, the line is not displayed in the default layout of the hit list and can be added by layout change.

The important measured values are ‘No.’ (col. 1), ‘Gross’ (col. 2), and ‘Net’ (col. 4). They tell you how often an operation was executed, and how much time it required, either as a total including sub-operations (Gross time), or without sub-operations (Net time). Remember that the times are measured in microseconds (ms) and that the shown times are the total times, not the times per execution.

The other columns contain additional, although less important information. These are the equality sign ‘=’ (col. 3), the percentages ‘Gross (%)’ (col. 5) and ‘Net (%)’ (col. 6), and also the ‘Type’ (col. 9) and the ‘No. Filter’ (col. 10).

Of the 15 function icons

most are standard ALV functions: sorting (icons 1 and 2), horizontal scrolling(icon 5 to 8), details (icon 9), ALV filter (icon 10), sum of numerical columns (icon 11), layout change (icon 12), sending (icon 13), downloading (icon 14), and finally information (icon 15).

Not standard ALV functions are the link to the source code (icon 3), and the filter (icon 4), which has ABAP Trace-specific settings. We recommend that you display everything.

This section introduces the hit list, which is the summarized view of the ABAP Trace like the SQL statement summary in the SQL Trace. It is explained what the hit list displays and what additional functions are hidden behind the icons. In the next section the hit list is used for the detailed analysis.

4. Checks in the Hit List

Start the checks in the hit list with the sort order ‘gross time descending’, which is also the default sort order.

High Gross Time = Expensive Branch
For the top 20, or better, for all lines with gross times larger than 10 ms, check whether they are really necessary, i.e. ask yourself if some of the executions can be avoided. It is not uncommon that operations are called too often. In terms of functional correctness this is not a problem, as the result is correct. It just means that the same result is computed several times.

Then resort the hit list by net times descending, so that you can see the top consumers:

High Net Time = Expensive Execution
Again, check the top 20 or all consumer with net times larger 10 ms. See whether the number of executions are reasonable or whether it could they be lower? Calculate the net time per execution and try to understand, why that amount of time is needed by analyzing the coding. Can the coding be improved to get better performance?

Finally, take a look at the large execution numbers. Do you understand the highest execution numbers? For example, why is an operation executed several thousand times? Is this necessary? Maybe you will realize that some of the executions are not really necessary.

The ABAP Trace can provide you with the figures, but it cannot know how much time an operation is allowed to need. This is something only you can determine, either by knowing the functionality or by checking the coding in detail.

It makes sense to classify the types of operations into different operations categories:

The modularization units, i.e. the methods, functions, and forms, contain the actual coding. Most of your analysis efforts should be focused on these areas.
The internal tables are a special part of the ABAP processing. It makes sense to check them separately in a further analysis step.
The RFCs (remote function calls) are special modularization units that run in another mode either on the same server or even in a different system. If they claim large fractions of the time, then you should also check the details of the RFCs.
The database operations are by default measured separately from the modularization units. This will always represent a considerable part of the total runtime. If individual operations use up a large part of the time, check them in detail with the SQL trace.
There are many other types of operations that are traced by the ABAP Trace. Usually, however, they are not critical to performance. Check them if they consume large portions of the net time.

These type categories will become more prominent in further developments of the SE30.

In this section, the details of the analysis are discussed. Check the top contributions in the hit list in detail and find out whether the coding can be optimized or whether the number of executions can be reduced.

5. Aggregation ‘None’

The aggregation ‘None’ provides much more detailed results, because every individual execution of an operation is traced; it covers a lot more screens than the aggregation ‘by call position’.

There are 8 hit lists: ‘Hit list’, ‘Group hit list’, ‘Database table hit list’, ‘Class hit list’, ‘Instance hit list’, Method hit list’, ‘Event hit list’ and ‘Internal table hit list’,
‘Call hierarchy’ (icon 9)
And ‘Statistics’ and ‘Display Filter’

The special hit lists are more or less just filtered views of the hit list and offer little new information. Only the call hierarchy offers something new. It shows all executions in the sequence of execution, with individual gross and net times plus level in the call stack. As you can imagine, a rather simple call hierarchy can already get very long.

As an example, I have reduced the call hierarchy of the simple example program, by selecting only the 4 modularization units on the second tab of measurement restrictions (left top corner), and switching on only the first entry in the display filter, which gives the following call hierarchy:

A standard business application will result in a call hierarchy with thousands of lines, if you use standard settings. Obviously nobody would ever analyze a call hierarchy in total, but only the parts that are of special interest. For a performance overview, the hit list is much more important.

This section gives a short overview of the extended functionality of the ABAP Trace for non-aggregated traces. Besides the additional hit lists, the call hierarchy is the most interesting feature. However, about 95% of all performance analysis sessions can be done with the hit list of the trace aggregated by calling position.

This blog explains the basics about the ABAP Trace with focus on performance. You should now be able to find the most critical performance bottlenecks in your system. Together with a similar blog on the SQL Trace (see The SQL Trace (ST05) – Quick and Easy), you should be able to get a good overview of the performance in your back-end system.