Transaction Step Cycle

Once an SAP user completes an entry. the presentation server sends the request to the dispatcher on the application server. The response time (Av. RESPONSE TIME) is measured from the moment the request from the presentation server reaches the dispatcher in the application server (step1). The response time ends when the request is processed, and the last data is sent back to the presentation server.

Dispatcher wait time

When the dispatcher receives a processing request, it looks for a free SAP work process of the required type (dialog. update, etc.) and then sends the request to this work process, which begins the work. If all SAP work processes of the required type are busy when the request initially reaches the dispatcher, the request is placed in the dispatcher queue (step2 ).

In the dispatcher queue, the request waits until a work process of the required type is free. As soon as a work process is free, the dispatcher sends the request to it (step3 ). The time the request spends in the dispatcher queue is indicated as the Av. WAIT TIME. Note that many other kinds of  wait times are involved in processing, for example, waiting for RFC calls, locks, CPU access, database access, and so on. To differentiate the wait time discussed here from others, it will be referred to more precisely as dispatcher wait time.

Roll-in and roll-out

An SAP transaction normally extends over several transaction steps (screenchanges). During these steps, data such as variables, internal tables, and screen lists are built up and stored in the main memory of the application server. This data is referred to as user context. Different transaction steps are normally processed by different dialog work processes. For example, the first transaction step may be processed by work process number three, the second transaction step by work process number four, and so on. At the beginning of a transaction step, the user context must be made available to the appropriate work process. This procedure is called roll-in (step4 ).
The technical processes comprising a roll-in, such as copying data to the local memory of the work process, Memory Management. Similar to the roll-in at the start of a transaction step, a roll-out is performed at the end of a transaction step; that is, the current user data is saved (step12 ). The duration of roll-in is referred to as roll-in time, and the duration of roll-out is known as roll-out time. Please note that the roll-out time is not part of the transaction step response time. At roll-out, when the user context is copied from the local memory of the work process to the roll memory, the processed data has already been returned to the presentation server.

Load time

All ABAP programs and screens that are required but not yet available in the application server buffers must be loaded or generated. The time it takes to do this is indicated as load and generation time (Av. LOAD & GEN.TIME). Loading a program also entails accessing database tables that store the ABAP programs

Database time

If data is read from the database server or changed in the database, these actions are indicated as database time (Av. DB TIME). Database time is measured from the moment the database request is sent to the database server and runs until the moment the data is returned to the application server (step6-step10)

Elements of  Database Time

Since the database time is measured by the application server, this includes not only the time that the database requires to provide the data, but also the time for the network transfer. Therefore, a network problem between the database and the application server will result in an increased database time. Furthermore, the database time also includes the time for the provision of data in the ABAP server. This can be written in the following formula: 

Database Time (ST03) = Database Server Time+ Network Runtime+ Data Transfer Time (Client/Server Communication)
The database times for direct read, sequential read and changes (including commits) are also determined on the ABAP server.

Before accessing the database, the database interface of the work process checks whether the required data is already in the SAP buffers. In this case, the SAP buffers are accessed directly because buffer use is up to 100 times faster than database access (step5 ). If the buffer is not filled, the database is accessed, and the data is then written to the buffer for subsequent accesses(step11 ). Buffer access does not contribute to database time.

Roll wait time

Roll wait time occurs in remote function calls (RFCs), in other words, when Roll wait time there is communication between software components or when there is communication with the presentation level.

GUI and enqueue time

The duration of communication between the presentation and application servers (network transfers and the creation of images on the presentation server) is included in the GUI time or in the frontend network time. 

Enqueue time is the time during which a work process sets an enqueue request (indicated as Av. LocK TIME).

Database procedure time

Database procedure calls are measured separately in the statistics. Database procedure calls are particularly relevant in APO systems because communication between APO instances and liveCache takes place via database procedures (also called COM routines). A new subrecord type, the database procedure subrecord, was introduced for analysis purposes. This new subrecord type contains the name of a database procedure and the name of the logical database connection as key fields, along with the number of calls and the total execution time as the data section. By default, these subrecords are not written. To activate writing, you must set the profile parameter to stat/dbprocrec . This is also possible in expert mode for a running instance in the workload monitor. In the workload monitor, the time needed to execute database procedures is identified as TOTAL ACCESS TIME OF DATABASE PROCEDURES. The database time in the workload monitor and in the single statistics records contains only times for calls to the actual database.

Processing time

Processing time is the total response time minus the sum of all times previously mentioned (except GUI time).

CPU time

All the times discussed so far are determined directly by the SAP work process; that is, whenever the relevant action runs, it is timed. With CPU time (Av. CPU TIME), on the other hand, the SAP work process asks the operating system at the end of a transaction step how much CPU time has expired during that step. The CPU time is thus determined by the operating system and is not an additive component of transaction response time (like the times mentioned above), but is in fact required during load time, roll time, and processing time. Figure 3.3 illustrates the CPU time as an element of the previously described times using dark blocks.