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.