ST05: Basic Use

[ManfredMensch]

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 Analyze 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, in area Select Trace Type (Fig. 1), mark the options that correspond to the types of communication you need to analyze. 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 communication interfaces across which the ABAP work process can exchange information with external components. They are listed in Table 1.

Table 1: Trace types covered by ST05.

SQL Buffer Enqueue RFC HTTP APC AMC

DB accesses calls to buffered objects handled by the application server’s buffers set or release SAP business locks (enqueues) remote function calls HTTP(S) communication WebSocket communication message exchange via publish/subscribe channels

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 technical frameworks. As a developer of a specific business application's coding you can do little to improve the immediate invocation of the event, but you are obliged to optimize your call to the framework. This call's 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 to activate tracing, 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. 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.

Table 2: Filter conditions for the display of trace records.

Trace Types	Select the trace types you want to analyze.​
Trace Period	After recording a trace, the default time interval extends from the time when the trace recording was started until it was ended. For previously recorded traces, specify the time interval manually.​
Client	Client where the traced activity was executed.​
User Name	Name of the user who executed the traced activity.
Object Name	Name of the object that was accessed. (SQL, BUF: table or view; ENQ: lock object; RFC: function; HTTP, APC: path; AMC: channel ID)
Duration [Microsecs]	Elapsed execution time of the operation in microseconds (µs).
Executed Operation	Operation that was executed.​
Database Connection Name	Database connection that was used to access the data.
Database Connection ID	Database connection ID used to process the statement.
Work Process Type	Type of the work process that executed the traced activity.
Work Process ID	Number of the work process that executed the traced activity.
Transaction ID	GUID that designates an SAP LUW.
EPP Root Context ID	The extended passport (EPP) correlates requests in complex business processes throughout the system landscape. The root context ID identifies the initial context.
EPP Connection ID	The connection ID distinguishes involved remote destinations.
EPP Connection Counter	The connection counter enumerates multiple calls that reuse a connection.

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 Trace Main Records, ST05 attempts to aggregate all these detailed records so that ideally there is a one-to-one correspondence between list entries 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 Start 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 ALV list of Trace 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.

Table 3: Fields in the default layout of the list of trace main records.

Start Time	Start time of the event in the user’s time zone.
Duration	Elapsed execution time of the event in microseconds (µs). (Measured by the ABAP work process.)
CPU Time	CPU time in microseconds (µs) used during the statement's execution. (Only for SQL trace records on SAP HANA.) (Measured by the SAP HANA DB server.)
Memory	Maximum memory consumption in kilobytes (kB) during the statement's execution. (Only for SQL trace records on SAP HANA.​) (Measured by the SAP HANA DB server.)
Records	Number of records affected by the event. (SQL, BUF: number of table or view rows; ENQ: number of lock granules) (Not for RFC, HTTP, APC, and AMC trace records.​)
Program Name	Name of the ABAP program that called the event.
Object Name	Name of the object that was accessed. (SQL, BUF: table or view; ENQ: lock object; RFC: function; HTTP, APC: path; AMC: channel ID)
Statement	Edited statement. (SQL: field list and FROM clause removed, variable names replaced by values)
DB Cursor	Number of the cursor used for the operation. (Only for SQL trace records.​)
SQL Statement Hash	Hash value of the SQL statement. (Only for SQL trace records on SAP HANA.​)
Array	Maximum number of records that can be transferred from the database to the ABAP work process within one communication package. (Only for SQL trace records.​)
Connection Name	Name of the logical database connection (default = R/3). (Only for SQL trace records.​)
User Name	Name of the user who executed the event.
Client	Client where the event was executed.
WP Type	Type of the work process that executed the event.

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 on the database server, 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.​

Table 4: Further fields for the list of trace main records, available on demand by changing the ALV grid control's default layout.

Start Date	Start date of the event in the user’s time zone.
Instance	Application server instance where the event was executed.
Processing Time	Elapsed execution time of the event in microseconds (µs). (Only for SQL trace records on SAP HANA.) (Measured by the SAP HANA DB server.)
Transaction Code	Name of the transaction that triggered the traced activity.
DB connection ID	ID of the logical database connection. (Only for SQL  trace records.​)
WP ID	Number of the work process that executed the traced activity.
Transaction ID	The transaction GUID designates an SAP LUW.
EPP Root Context ID	The extended passport (EPP) correlates requests in complex business processes throughout the system landscape. The root context ID identifies the initial context.
EPP Connection ID	The connection ID distinguishes involved remote destinations.
EPP Connection Counter	The connection counter enumerates multiple calls that reuse a connection.

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 ST05: Aggregate Trace Records, I present 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. In my most recent blog post ST05: Analyze Individual Trace Records I describe their in-depth analysis.

Summary

Getting started with ST05 is really easy and takes only a few clicks. Just start the tool, 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.