Register Login

Definition of SAP response time/processing time/CPU time

Updated May 18, 2018

The response time of a transaction step is the difference between the time when the request arrives in the R/3 system and the time when processing in the R/3 system is complete.

In addition to this measurement of time, various other times are measured in the R/3 system, such as wait time or database time. When you subtract these components from the response time, the processing time remains, which cannot be measured directly. ABAP program code is processed during the processing time.

The processing time is calculated as follows:

Processing time = response time
- Wait time                  the dispatcher is waiting for a free
                              work process (= dispatcher queue).
- Load/generating time                        for loading/generating
                              screens, ABAP programs, and CUA
                              elements (not in presentation).
- DB time                    for accessing and waiting for the data-
                              base interface and, therefore, for the
                              underlying database.
- Roll-in time                for the roll-in of the roll area
                              context of a dialog step and possibly
                              for a dialog step that is waiting for RFCs
                              (as of Rel. 4.0A, also called 'roll wait
                              time', see below for more information).
- Enqueue time                for setting a logical SAP enqueue.
- DB procedure time           time for processing DB procedures
                              in the database (as of Rel. 4.6C; for
                              example, in liveCache).

The CPU time is specified only as a total per transaction step in the workload statistics and is part of the response time. Note: The CPU time must not be added to the times listed above because it is specified as a total and consists of parts of the times listed above that cannot be calculated.
The CPU time is returned by the operating system. The accuracy of the reported value depends on the timer of the operating system (on UNIX, for example, the timer works with 100 Hz so that the CPU time is reported as a multiple of 10 ms).
Due to this rough resolution of the CPU time, a slightly longer CPU time may be displayed for a dialog step than for the response time.

The roll-out time is not part of the response time because the roll-out occurs only after the data is transferred to the presentation server.
The roll wait time is a time during which a work process waits for the response of an RFC. Up to and including Release 3.0F, it is included in the response time for all task types (if you have not implemented Note 63476). In higher releases and after you implement the note, the roll wait time is no longer part of the response time for transaction steps of task type RFC. The reason for this is that the roll wait time is no longer considered to consume resources on the calling application server, that is, the client. As of Release 4.0A, the roll wait time is specified separately.
The roll wait time is time that elapses on the client while the user context is in the roll area. Therefore, no resources are used on the client and there is no bottleneck here if the roll wait time is long. The server is active at that time and may cause the long response times on the client. A transaction step of type RFC may be created on the server if an RFC to another R/3 application server is concerned. However, this may also be an external program that was started via RFC.
As of Release 4.0, long roll wait times occur frequently. This may be caused by calls of Windows or other external applications from within the R/3 system. In this case, the application is started via RFC, the user context enters the roll area, and roll wait time elapses until the the application is closed, that is, the RFC connection is closed. It is only then that the transaction step is completed.
As of Release 4.6, roll wait times also occur when the R/3 system communicates with the controls in the front end. While the data in the front end is processed, the R/3 context is rolled out, and the work process is released as a result. This may occur several times during a transaction step. If front-end office applications (such as Microsoft Word) are started and only closed after a long time (more than several minutes), a very long roll wait time also occurs.


×