When you have invested in hardware and software to support your business processes, you want to ensure that they are running optimally. Otherwise, you risk making your end users less efficient or seeing your IT costs rise. For these reasons, performance optimization projects will always be important. Tuning your software solutions will significantly improve the return on investment (ROI) for your IT infrastructure. Before you can tune an application, though, you need to identify where the issues are coming from.
For example, for SAP solutions based on the SAP NetWeaver client-server architecture, most of the business logic is executed by the work process. To accomplish its tasks, the work process may need to call external resources, especially the database. Understanding the details of such requests is crucial for tuning the performance of individual applications. Requests to shared central resources in particular must be limited to the absolute minimum and must be optimized as much as possible.
With the Performance Trace (transaction ST05), you can determine the origin of issues in your applications. This transaction is a tool for recording requests that leave or enter the work process (these recordings are called traces) and then displaying the trace records as a list. It also provides extensive support for examining individual trace records.
In this article, I will explain how to use ST05 and what to look for when analyzing the results.1
Additional ST05 Start Screen Options
Besides allowing users to start a basic trace, the ST05 start screen also includes other options:
- Setting Stack Trace to On allows you to include the ABAP call hierarchy in the trace.
- Clicking Activate Trace with Filter opens the popup, Conditions for Trace Recording, (see Figure 1) where you can overwrite defaults for trace recording.
You can keep track of trace activities on the current server by checking the Trace Status area, which indicates when and by whom the trace settings were last changed, the currently active trace type(s), and the user whose actions are recorded. Note that this information is specific to the current SAP instance.
Recording a Trace
To access the Performance Trace, you can use transaction code ST05 or, since it is fully integrated into the ABAP Workbench, you can access it from the workbench by following the menu path System → Utilities → Performance Trace.
To record a trace, open the ST05 start screen (see Figure 1), use the check boxes in the Select Trace Type frame to choose the trace type(s), and choose Activate Trace to switch the selected trace type(s) on. Once you’ve activated the trace, you can then run the application you want to analyze on the server where the trace was activated. When the application is finished, choose Deactivate Trace to stop the recording.
||ST05 start screen; including the Conditions for Trace Recording popup
When running a trace, it’s important to keep a couple of things in mind:
- On an application server, only one user at a time can record traces.
- Tracing for long periods of time may lead to incomplete traces with missing beginnings. This is because traces are written to dedicated files on the application server; when all trace files are full, the oldest file is deleted and a new file is created.
Analyzing a Trace
Once you’ve recorded your trace, the next step is to analyze it, looking for bugs, issues, and areas that need performance improvements.
To view a trace, choose Display Trace (refer to Figure 1) on the server where the trace was recorded and, in the subsequent selection screen, specify any criteria for filtering the records to be displayed. The standard trace display is a chronologically sorted list of main records. Each record corresponds to one execution of an ABAP statement, and contains the accessed object, the edited statement, the calling program, and the details on the statement’s processing (see Figure 2). The duration (in microseconds; µs) or the number of affected table rows (Records) are likely the most relevant values for judging performance.
||In the Trace Display, each call to an external resource, triggered by one execution of an ABAP statement, is reflected by one main trace record
Once you’ve identified potential problems, you can further drill into the associated trace records. For instance, you can investigate long-running statements through tools linked with the Trace Display screen. These tools do the following:
- Show details of the request, including variable values for SQL, buffer, and enqueue traces
- Display comprehensive Data Dictionary (DDIC) information on the table or lock object
- Show the database’s execution plan for SQL statements
- Navigate to the calling statement in the ABAP source code
- Reconstruct the entire ABAP call stack leading to the statement
For SQL and buffer traces, the trace contains details of individual operations that served such statements. You can display these details by double-clicking the row header of the trace record. Higher levels of aggregation (available through the Aggregate Trace button, ) provide a better overview and deeper insight into the entirety of the requests sent to external resources.2
Through this trace aggregation, you can identify:
- Structure-identical statements: These statements touch the same object and have the same structure. WHERE clauses in particular use the same variables, comparisons, and logical operators in identical order.
- Value-identical statements: If all the variable values of structure-identical statements match as well, these statements are value identical.
If you’re working on a performance optimization, I recommend taking a closer look at the list of structure-identical statements as a good starting point (see Figure 3). By default, the structure-identical statements list is sorted by duration in descending order so that the most expensive statements are at the top of the list. Further indicators of the load generated by a statement are the total numbers of executions and records.
||In the list of structure-identical statements, metrics of individual statements sharing the same structure are summarized and augmented by various statistic values and technical properties of the table
You can identify performance bugs by looking for non-zero values in the Redundancy and Identical columns (these show the absolute and relative numbers, respectively, of value-identical statements). You can also check the entries in the Buffer Type column to find out if table content is read from the database even though the table’s technical settings (or data) allow buffering. Both of these kinds of unnecessary database accesses waste precious resources and increase an application’s response time.3
Statements with an average Duration/Record that exceeds 10,000 µs are too slow and their execution plans should be investigated. (For changing SQL statements, the threshold is twice as high.) For statements with high values in the Executions or Records columns, check whether they can be called less often or rewritten so that they return fewer records. If the value of Records/Execution equals 1 and the statement is executed often, an array access should be considered. Statements that return no records at all are also dubious and might require further investigation.
With this kind of information about how your application works and where improvements could be made, you will be armed and ready to optimize the performance.
For companies looking to optimize the performance of their critical applications, being able to identify the sources of performance problems is the key to success. The Performance Trace’s ability to identify potential areas of optimization based on purely technical criteria allows centralized and automated performance analyses. The information contained in the trace records also supports in-depth approaches relying on specific application knowledge.
With this tool, companies will be better equipped to analyze the source of slow applications so they know exactly where to aim their performance-tuning efforts.
Manfred Mensch (firstname.lastname@example.org) studied physics and mathematics at the University of Karlsruhe. He received his Ph.D. in environmental physics from the University of Heidelberg. After further years of research in the US and in Germany, he joined SAP in 2000 and has been a member of the Performance and Scalability team since 2006. His responsibilities include supporting his colleagues in SAP’s OnDemand organization by coaching and consulting with respect to performance during the design, implementation, and maintenance phases of their software. Currently, Manfred is focusing on the development of trainings and performance analysis tools.
1 The example in this article uses the SQL trace (which allows you to investigate database accesses) to demonstrate the capabilities of ST05. Additional trace types cover access to various buffers (most notably the table buffers) in the application server’s shared memory, outgoing or incoming requests using RFC or HTTP, and calls to the enqueue server. These traces can be used in a similar way to the SQL trace. [back]
2 Some of the aggregation levels support only SQL, buffer, and enqueue traces. [back]
3 A trace may contain further unnecessary statements, the identification of which requires application knowledge. [back]