This is the first blog post in a series of posts that cover my SAP GUI transaction ST05. Here, I show the straightforward use of the tool to get you started for ad hoc performance analyses of your business applications.

If you have not yet done so, please read the introductory post Use ST05 to Monitor the Communication of the ABAP Work Process with External Resources. There I explain how my transactions STATS and STATS_FE help you to detect performance bugs in your applications. That post also introduces ST05 as an essential analysis tool to find root causes for applications that are too slow or consume too many resources. In particular, it captures and logs communications and data transfers between the ABAP work process and external components. By default these transmissions are not recorded to avoid the associated overhead.

You start the Performance Trace (sometimes also called Performance Analysis) with transaction code ST05. On its start screen (Fig. 1), mark the options that correspond to the types of communication you need to analyse in area Select Trace Type. This choice shall correspond to the critical interfaces identified by previous measurements of the application under investigation, e.g., with transactions STATS or STATS_FE.

Figure 1: In area Select Trace Type on the ST05 start screen, you mark the relevant trace types. Determine whether the ABAP call hierarchy shall be recorded in section Configure Trace. Then switch on tracing on the local application server instance by clicking Activate Trace. The Trace State panel displays the current settings.

ST05 supports seven interfaces across which the ABAP work process can exchange information with external components. They are listed in Table 1.

The most common trace type (pre-selected by default) is the SQL Trace. It addresses communication with the database server. A more appropriate name would be DB Trace, because only SQL statements sent to the database will be recorded. To capture SQL statements handled by the table buffer in the ABAP application server instance you must mark option Buffer Trace.
In the Configure Trace area you can decide whether relevant communication activities shall be recorded together with their triggering ABAP call hierarchy (Stack Trace = On). During subsequent trace analysis, this is especially helpful for events encapsulated within and called via generic frameworks. As a developer of specific application coding you can do little to improve the immediate invocation of the event, but you are obliged to optimize your call to the framework. Its source code is accessible by the ABAP call stack. If you set Stack Trace = Off (default in customer systems), only the immediate caller will be recorded.

To start tracing click button Activate Trace. This switches on the trace recording only on the local ABAP application server instance and exclusively for the current user. Activities on other instances or by other users are not traced. Area Trace State indicates the date and time of the last change, and the name of the user who did the change (Fig. 2). It also shows the active trace types and the name of the user whose activities are traced. (With the current method, this is your user’s name.)
If recording is already active on the instance, you cannot start another recording. You must wait until the other user ends the recording.

Figure 2: On the ST05 start screen, the Trace State area indicates the current situation on the local application server instance. When the process under investigation has finished, Deactivate Trace. Then click Display Trace to work on the records.

Execute the process in the normal way. You must ensure that it runs for the same back-end user who activated tracing, and that it gets executed on the application server instance where you have switched on the recording.

Once the application has completed, return to the ST05 start screen (Fig. 2). Switch off the recording by clicking Deactivate Trace. To start the analysis, click button Display Trace. This takes you to the Filter Conditions for Trace Records (Fig. 3). There you can specify restrictions on the subset of captured trace records to be examined. The appropriate filter conditions are pre-populated as much as possible with values that correspond to the previous activate – deactivate cycle. This applies in particular to the Trace Types, and to the Trace Period, which starts at the time of the last trace activation and ends at the time of the last trace deactivation.

Figure 3: Define filter conditions for trace records to be displayed and analyzed. Entries in areas Trace Types and Trace Period are prefilled with data matching the previous trace recording. With entries in section Trace Filter, you can concentrate on a subset of the trace with specific properties.

In the Configuration area, you may overrule the default to work on trace records only from the Local application server instance. Alternatives are all Active instances, or an Individual subset of all application server instances. (Recall that the click on Activate Trace records only on the local instance.) Due to load balancing, after a new logon you might be working on another application server instance. If you know the instance where your trace was recorded, choose it from the Instance Selection popup that comes up after clicking Individual.
The option Max. Number of Records guards against traces with an unexpectedly large number of records. A popup will indicate when the given number of records has been read and processed. You can then decide whether you want to continue or abort. The default value is 5000 records, and the system will remember your most recent value. You may also set your personal default with user profile parameter ST05_MAX_REC_NUMBER.

In area Trace Filter you may set restrictions (Tab. 2) to focus your attention on particular details. This is helpful in exceptional cases, but rarely used. Ensure that you do not suppress important information by applying a filter that is too restrictive. Also be aware that it might interfere with displaying the ABAP call stack.

When you execute, the available trace records that meet the filter conditions are retrieved, handled, and displayed in an ALV grid control. The standard trace display (Fig. 4) is a chronologically sorted list of main records, each corresponding to one execution of an ABAP statement. (The processing of the statements in your application’s ABAP source code may involve several contributing operations that are captured as individual, detailed records in a trace. For the list of main records, ST05 attempts to aggregate all these detailed records so that ideally there is a one-to-one correspondence between main records and implemented ABAP statements. Individual records that cannot be aggregated are collected into dummy main records with the Statement set to OTHER (<trace_type>) and empty Time.) All types of trace records are shown in one common table, using only those fields that are relevant for the respective record’s type, and leaving the others empty.

Figure 4: In the list of main records, each entry reflects one execution of an ABAP statement calling an external resource, or the processing of an incoming request.

Table 3 documents the fields that are visible by default.

Every trace record contains the abbreviated statement, focussing on the parts with an impact on performance, and the object accessed by the statement. Also available is the calling program, and some details on how the statement was processed. The Duration (in microseconds; μs) or the number of affected table rows (Records) are likely the most relevant values for judging performance. If your system is based on the SAP HANA database, SQL trace records include measurements for the CPU Time and for the Memory Consumption, and identify the statement with its SQL Statement Hash.

The second header line at the top of the list summarizes the visible trace records by showing totals for Duration, CPU Time, and Records, and the maximum for Memory Consumption. Note that the total Duration is not necessarily related to the application’s elapsed time. In the example of Fig. 4, the incoming HTTP request triggered SQL statements which were executed during the HTTP request’s duration. Thus the total Duration may overestimate the elapsed time.

Further fields (listed in Table 4) may be shown by customizing the ALV grid control’s layout.​

The list of main records helps you to judge the choreography of executed statements. In particular, it answers the question: Which event was executed when and where? This may allow you to conclude that statements are executed although they do not contribute anything to your application’s business logic. These superfluous statements slow down your application, and at the same time waste precious resources. You must eliminate them. In my follow-up blog post Aggregate Trace Records, I am presenting an easy and reliable method to find these unnecessary statements in a trace and in your application’s ABAP source code.
For the remaining essential events, you focus on the statements that have a long Duration, affect many Records, or consume a lot of HANA hardware resources (CPU Time, Memory). They offer the largest optimization potential. The sequel blog post quoted above also discusses how to identify statements that would benefit the most from tuning.

Summary

Getting started with ST05 is really easy and takes only a few clicks. Just start the transaction, and click button Activate Trace. Then execute the application you want to analyze. When it has finished, return to ST05 and click button Deactivate Trace. Finally click Display Trace and execute to evaluate the trace records. The analysis of the trace records will discover hot spots and bottlenecks of your application related to its communications with external resources. The most important caveat is that all steps have to be done on the same application server instance and by the same back-end user.