The ABAP Runtime Trace (SE30)

1. Using the ABAP Runtime Trace

Using this tool is nearly as straightforward as using the SQL trace 

1. Call the ABAP Runtime Analysis (transaction SE30)
2. Check the measurement restrictions and change them if necessary. See the recommendations below.
3. 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.
4. Execute your test program directly from the ABAP Trace. This is possible for transactions, programs, and function modules.
5. Switch off the trace.
6. If a trace file was written, it will appear under ‘Performance Data File’.
7. 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

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. 

• 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’