This blog post in my series of posts related to SAP GUI transaction ST05 (introduced in Use ST05 to Analyze the Communication of the ABAP Work Process with External Resources) explains the tool’s inner workings and configuration options, and how they affect its behavior. With this knowledge, you can avoid some pitfalls that otherwise would make your performance analyses less convenient or less reliable.
My blog post ST05: Basic Use describes the straightforward work with this analysis tool so that you can record your applications’ communications with external resources across the boundaries of the ABAP work process. This current post does not teach you any new tricks, and you may safely ignore it at first—as long as you remember it exists when you feel that ST05 misbehaves. Then the tool’s technical background as presented here does explain that ST05 actually works as designed.

Authorizations

Transaction ST05 is protected by authorization object S_ADMI_FCD, which checks accesses to various basis functions. It defines a single authorization field, also called S_ADMI_FCD, for these system administration functions. The relevant values are

• ST0M   Authorization to activate or deactivate trace recording

• ST0R   Authorization to analyze traces

There are no further checks. In particular, every user with the authorization to switch tracing on or off can deactivate a trace recording switched on by any other user. Similarly, every user with the authorization to analyze traces may see all available trace records, independent of who activated their recording, or who triggered the recorded event.

Trace Recording

ST05 really is just a display transaction. The only changes it can trigger are via buttons Activate Trace and Deactivate Trace (and the closely related buttons Activate Trace with Filter and Deactivate Trace on All Instances). These actions modify the so-called SWitches Block (SWB) in the Shared Common System Area (SCSA), a small shared memory segment accessed by SAP executables (kernel programs). The SWB content determines whether tracing is on or off, which trace types (i.e., communication interfaces) are to be recorded, and what filter conditions shall be applied. The actual capturing of the communication events is done by the ABAP kernel.
Because the SCSA is shared across the entire application server instance, trace recording does not work concurrently, i.e., ST05 cannot capture communication events triggered by distinct users (or by distinct user groups defined with a trailing wildcard *).
With one SCSA per instance, tracing is instance specific so that at the same time it can be active for one user on one instance, and for another user on another instance (and inactive on all other instances). This also demands that the application whose communication requests you want to capture runs on the instance where trace recording was switched on. Simple trace evaluation via the Display Trace button is also instance specific, i.e., only works with trace records previously captured on the same application server instance. Altogether, trace recording, application execution, and trace analysis must all be done on the same application server instance.
Trace recording is always cross-client: Active tracing captures communication events related to each and every client in the system.

When trace recording is active, the kernel saves trace records into  dedicated (binary) files on the application server instance’s file system. The base name of these files (including the path) is fixed by the value of profile parameter rstr/filename (e.g., /usr/sap/YI3/D34/log/TRACE). New trace records are always stored into a file by exactly this name. When it is filled to its capacity (as defined in megabytes by profile parameter rstr/max_filesize_MB; default value 16, maximum value 100), the file is renamed by appending a two-digit number between 00 and 99 to the base filename. If a file by that name already exists, it will be discarded. An empty file with the base filename is recreated, and trace recording into this newly created file continues without any gap. The maximum number of trace files (active plus overflow) is defined by profile parameter rstr/max_files (default value 10, maximum value 99). If this number of files is exceeded, the oldest file is deleted, and recreated to act as the youngest overflow file. As a consequence of this round-robin approach, old trace records are eventually lost, and a trace may overwrite its own beginning if recording is active for too long or if the traced application triggers a large number of recorded events. Depending on the specified filter conditions for trace recording (cf. my blog post ST05: Activate Trace Recording with Filter), on the load on the application server instance, and on the configured number and size of trace files, this may happen within just a few minutes.

To minimize the impact of trace recording on the instance’s performance, the records are not appended immediately and individually to the trace file, but first cached in an internal memory buffer within the ABAP work process. This buffer’s size (in kilobytes) is given by profile parameter rstr/buffer_size_kB (default value 500). If the size of a single statement (including its variables’ values) exceeds this value, it will be truncated.

The method used for trace recording, as described above, implies that on the technical level there are only individual trace records, stored one after the other. The concept of a trace as a set of records that belong together has no technical realization. Of course it is still a useful mental notion when you work with ST05 to analyze your application’s communication events.

Based on benchmark runs, the average size of a trace record is less than 1kB and the overhead for server response time, as well as ABAP CPU time, is less than 3%.

Additional Trace Types

The SWB in the SCSA supports more trace types than are exposed by ST05. The corresponding interfaces deal with authorization checks done by your applications, or with low-level calls to the kernel’s C functions or C modules. You can control and analyze these trace types in transaction ST01, together with the others, which are more frequently used and therefore accessible in ST05.
The inability to trace concurrently also extends to these ST01-only trace types. Thus, in rare cases your attempt to record a trace with ST05 may fail although the Trace State area on its start screen is empty. An information popup will then explain the situation: At least one trace type was already activated for user <NN>. (This may be an ST01 trace.) The trace is not activated.

Stack Trace

As I have described in my blog post ST05: Basic Use, in the Configure Trace area on ST05‘s start screen you can request  that relevant communication activities shall be recorded together with their triggering ABAP call hierarchy (Stack Trace = On). With the setting Stack Trace = Off , which is the default in customer systems, only the immediate caller will be recorded.
The recording of the stack trace uses a delta strategy. Each trace record stores only those parts of the corresponding event’s ABAP call stack that have not yet been captured in previous records. The correct and complete ABAP call stack is assembled only at display time, i.e., on demand. This approach minimizes the recording overhead for including the stack trace, and—equally important—the size of the trace records does not grow too much so that precious space in the trace files is saved and available for further trace records. This technique comes with a disadvantage: If you apply a filter to the trace records at display time, parts of the call hierarchy may not pass the filter. Then the ABAP call stack cannot be reassembled. ST05 detects this situation and indicates it with a warning popup: Cannot fully display ABAP call hierarchy for statement of selected trace record. To avoid this type of problem, do not filter records when you display a trace taken with Stack Trace = On. Prefer to set a filter already while tracing, which saves even more space in the trace files.

Capturing call stack information takes ~30µs per trace record, and increases the record size on average by ~50%.

Profile Parameters

The table below summarizes the profile parameters that control how the trace recording works.

References

SAP note 12715 (Collective note: problems with SCSA) covers potential issues with the SCSA.