eG Monitoring
 

Measures reported by AsAbapTranLdTest

SAP transactions are units of work that define the workload of a SAP ABAP system. When users to a SAP ABAP program complain of a slowdown, administrators should be able to instantly locate the exact transaction at which the slowdown occurred and what is causing the delay - is it because the transaction is resource-intensive? Is it because the transaction spent too much time in the dispatcher queue? is it owing to the time spent loading objects? Is it because database operations consumed too much time? Is it due to complex enqueue operations? or did waiting for RFC calls to complete contribute to the transaction slowdown? The AsAbapTranLdTest test helps answer these questions!

For every transaction invocation, this test reports the resource usage of and load imposed by that transaction on the SAP ABAP system, indicates how well the system is processing the load, proactively detects overload conditions and processing bottlenecks (if any), and accurately points administrators to the source of the bottlneck - i.e., it precisely pinpoints which transaction is being processed slowly, which exact transaction step caused the delay, and why.

The measures made by this test are as follows:

Measurement Description Measurement Unit Interpretation
Activity Indicates the rate of steps executed for this transaction in the last measurement period. Steps/Sec This is a good indicator of the workload imposed by a transaction on the SAP ABAP instance. You can compare the value of this measure across transactions to know which transaction is generating the maximum load.
AvgCpuUtil Indicates the percentage of CPU resources utilized by this transaction. Percent Compare the value of this measure across transactions to know which transaction is using the maximum CPU and is probably causing a CPU contention on the system. You may then want to observe how this transaction has been using CPU over time and figure out whether the CPU usage of that transaction remains consistently high; if so, it could mean that that transaction requires more processing power to execute. You may then want to consider resizing the SAP ABAP system with more CPU resources.
ExtSessMem Indicates the total memory used by this transaction during the last measurement period. MB This measure is the sum total of the roll memory, extended memory, and heap memory used by a process.

By comparing the value of this measure across transactions, you can accurately identify that transaction which is consuming the maximum memory. If the memory usage of this transaction has been abnormally high consistently, it could indicate that the transaction is basically memory-intensive and requires more memory resources for proper execution. You should then figure out how much memory and of what type should be allocated to the task. For this, you may want to determine which memory type was being used the highest over time - is it heap memory? Roll memory? Or extended memory. The values of the PrivMem and the IntSessMem metrics will help administrators figure this out.

You can also use the detailed diagnosis of this measure to identify the top 3 memory-consuming steps of a particular transaction.

PrivMem Indicates the maximum PRIV mode heap memory consumed by this transaction in the last measure period. MB SAP's memory management system assigns memory to a work process. The order in which a work process is assigned the memory type depends on the work process type, either dialog or non-dialog), and the underlying operating system. Some of the memory types are as follows:

  • Roll area: The roll area memory is used for the initial memory assigned to a user context, and (if available) for additional memory if the expanded memory is full. The roll area consists of 2 segments. The first segment is assigned to the work process first as memory. If this is used up, the work process has more memory assigned to it.
  • Extended memory: Each ABAP work process has a part reserved in its virtual address space for extended memory. The majority of the user context is stored in the extended memory. You can map the extended memory from the common resource onto any work process, and after onto another process on the same address in the virtual address space. This is important if you work with pointers in the ABAP program. The value of the IntSessMem measure indicates how each user is using this memory type.
  • Private memory: If a dialog work process has used up the roll area assigned to it and the extended memory, private memory is assigned to the work process. The work process goes into PRIV mode (private). Other processes cannot use private (heap) memory. After releasing the assigned memory, the operating system still considers the (virtual) memory as being occupied by the allocating process.

    A consistent increase in the value of the PrivMem measure for a user therefore indicates that transactions of that user are continuously using up all the roll area and extended memory, and are being forced to reach out to the private memory. This could mean that the user transactions are memory-intensive. If too many transactions are found to be using PRIV heap memory, it could mean that the work processes are sized with insufficient roll area and extended memory. You may hence want to allocate more roll area and extended memory to make sure that private memory usage is minimal.
IntSessMem Indicates the maximum extended memory used by this transaction in the last measure period. MB
WPRestarts Indicates the number of work process restarts caused by this transaction in the last measure period. Number One of the common reasons for work process restarts is excessive usage of private memory. The work process, if it has used a lot of private memory, is restarted when the user context is terminated and the local memory is returned. The restart makes the local memory available again for other processes.

Regardless of what caused it, work process restarts are performance-impacting and need to be kept at a minimum.

MaxRespTime Indicates the maximum response time of the transaction steps of this transaction in the last measurement period. Secs An SAP transaction normally extends over several transaction steps. 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 measure compares the response time of all the transaction steps executed by a transaction in the last measurement period and reports the highest response time.

Use the detailed diagnosis of this measure to identify the top 3 steps executed by this transaction with highest response times. This leads you to the probable cause for delay in the execution of a transaction in the last five minutes. Apart from the response time break up, the report and CUA programs that were running are also shown as part of detailed diagnosis.
StepRespTime Indicates the average response time of a step executed for this transaction in the last measurement period. Seconds/Step This measure is used by the BASIS administrators for comparing the response time across all the transaction steps executed by a transaction to determine which step is taking longer duration for execution.
AvgUserRespTime Indicates the total response time per invocation of this transaction within the last measure period. Seconds/transaction This measure includes the response time taken at the server and the round trip times. Ideally, the value of this measure should be low. High values are indicative of poor responsiveness.

Compare the value of this measure across transactions to identify which transaction is least responsive. To know the reason for the delay, you can compare the value of the guitime, guiNetTime, AvgRespTime, proctime, WPwaitTime, loadGenTime, avgRollTime, DBReqTime, locktime, and rfctime measures for that transaction. This will accurately pinpoint where a transaction spent maximum time - in the dispatcher queue? at the server end? in processing? when loading objects? when rolling in user contexts? when performing database operations? when performing enqueue operations? Or in waiting for RFC calls?

You can also use the detailed diagnosis of this measure to view the details of the top 3 transaction invocations that were least responsive.

guitime Indicates the average time taken for round trip communication steps between client and server in between an invocation of this transaction. Seconds/transaction If the values of these measures are excessive, check that the hardware requirements for the presentation server are met and that the network between the application servers and the presentation servers is not experiencing shortages or slow traffic.
guiNetTime Indicates the average front end net time taken for the first and last steps of this transaction. Seconds/transaction
AvgRespTime Indicates the average response time of an invocation of this transaction at the server end. Seconds/transaction In the event of a processing slowdown, you can compare the value of this measure with other response time measures reported by this test to understand where the processing bottleneck lies.
proctime Indicates the average time taken to process an invocation of this transaction. Seconds/transaction A high value for this measure may indicate that ABAP programs are very complex and the work processes spend a large amount of time interpreting what is to be done.

The processing time of transactions executed by the dialog work process for instance should be below twice the CPU time.

WPwaitTime Indicates the average time that an invocation of this transaction spent waiting for a free work process at the dispatcher. Seconds/transaction When the dispatcher receives a processing request, it looks for a free SAP work process of the required type 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. 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. This time the request spends in the dispatcher queue is indicated as the WPwaitTime.

For the transactions of the dialog work process for instance, the value of this measure should be less than 10% of the value of the AvgUserRespTime measure. Higher values are indicative of performance problems. One common cause of such performance problems may be insufficient work processes.

loadGenTime Indicates the average time spent by an invocation of this transaction for loading and generation. Seconds/transaction 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 loadGenTime. Loading a program also entails accessing database tables that store the ABAP programs.

Typically, for the transactions of the dialog work process, the load time per step should not be greater than 50 ms.

High values could indicate problems with memory configuration, small buffer sizes, wrong parameter settings or a CPU bottleneck.

avgRollTime Indicates the average time spent by an invocation of this transaction for rolling in user contexts and when waiting for roll out. Secs AN SAP transaction normally extends over several transaction steps. 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 known as user context. Different transaction steps are normally processed by different dialog work processes. At the beginning of a transaction step, the user context is made available to the appropriate work process.This procedure is called roll-in. Roll-out on the other hand saves the current user-context data to virtual memory at the conclusion of a transaction step. The time a transaction step waited in the roll-area is called roll wait time.

The value of this measure is the sum total of roll-in time and roll wait time.

A high value for this measure indicates that the user transaction is either taking too long to roll in user contexts or is waiting too long in the roll-area for a roll-out to occur. Since a user context is moved out of the local memory of a work process and moved into the roll buffer during the roll-in process, improperly sized roll buffers can cause slowdowns in this process. Lack of adequate space in the extended memory can also contribute to a slowdown when rolling in user contexts.

Possible causes for high roll wait times may be due to having all work processes in the target system occupied. It is very important to configure the instances properly, especially when they are designed to handle RFC communication.
DBReqTime Indicates the average time spent by an invocation this transaction for performing database operations such as selects, inserts, updates, deletes and commits. Seconds/transaction When data is read or changed in the dataase, the time required is known as Database request time. This 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.

Ideally, for the transactions of the dialog work process, the value of this measure should be 40% of the total response time. Many factors can cause worrysome spikes in this value. This could be problems in the database such as expensive SQL statement or wrong parameter settings in the database level. In addition, issues in network connectivity between the application server and the database can also adversely impact this value. This is because, the DBReqTime not only includes the time required by the database to produce the requested data, but also the time required for network transfer of that data. In addition, I/O contentions experienced by the physical disks can also affect this time.

locktime Indicates the average time that an invocation of this transaction spent performing enqueue operations. Seconds/Transaction The enqueue service allows SAP ABAP applications to lock data so that only they can use it. Locking the data prevents parallel changes to the same data, which would lead to data inconsistency.

The locktime measure reports the time from sending an enqueue request to the SAP enqueue server to the receipt of the results.

For the transactions of the dialog work process for example, the locktime should be less than 5 ms. Any value higher than that would represent a problem that might affect system stability. Network problems can also increase the value of this measure.

rfctime Indicates the average time an invocation of this transaction spent waiting for RFC calls to get executed. Seconds/Transaction The value of this measure includes CPIC (Common Programming Interface Communication) time as well. CPIC is typically used by the SAP system for program-to-program communication.

An increase in RFC time can increase roll wait time considerably. When synchronous RFCs are called, the work process executes a roll out and may have to wait for the end of the RFC in the roll area, even if the dialog step is not yet completed. In the roll area, RFC server programs can also wait for other RFCs sent to them. The time a transaction step waited in the roll-area is called roll wait time.

The absence of adequate work processes can cause the RFC time and consequently, the roll wait time to increase. Besides ensuring that the SAP ABAP system is sized with sufficient work processes, you can also set the following parameters properly to better balance RFC load:

  • rdisp/rfc_max_comm_entries: This specifies the maximum number of communications in an instance. No more dialog work processes will be given to the program calling the target system after this number is reached.
  • rdisp/rfc_min_wait_dia_wp: This specifies the number of work processes to be always available for online users.
Invocations Indicates the number of active transaction invocations for this transaction in the last measurement period. Number Ideally, the value of this measure is should be low. A high value indicates high load on the transaction level.
NewInvocations Indicates the number of new invocations for this transaction in the last measurement period. Number This measure is useful for calculating number of transaction invocations that are newly made by a particular user in a specified time duration.

Use detailed diagnosis of this measure to findout the exact invocation timestamp, program, terminal and other details for a first transaction step of each new invocation.