eG Monitoring
 

Measures reported by AsAbapUsrLdTest

When a user complains that the SAP ABAP system is taking too long to process his/her requests, administrators may want to closely observe the interactions between that user and the SAP system, identify processing bottlenecks (if any), and accurately determine where the bottleneck has occurred. The AsAbapUsrLdTest test enables administrators effectively and efficiently perform this user experience analysis! This test monitors the transactions of every user to the SAP ABAP system and reports the following:

  • Which user is executing resource-intensive transactions on the ABAP system?
  • Which user is overloading the system?
  • Which user is experiencing slowness when running transactions on the system? Where did this delay occur? - in the dispatcher queue? when loading/generating objects? when rolling-in/rolling out user contexts? in the database? when performing enqueue operations? or when waiting for RFC calls to complete?

The measures made by this test are as follows:

Measurement Description Measurement Unit Interpretation
Activity Indicates the rate of steps executed for this user's transactions in the last measurement period. Steps/Sec This is a good indicator of the workload imposed by a user on the SAP ABAP instance. You can compare the value of this measure across users to know which transaction is generating the maximum load.
AvgCpuUtil Indicates the percentage of CPU resources utilized by this user's transactions. Percent Compare the value of this measure across users to know which user is using the maximum CPU and is probably causing a CPU contention on the system. You may then want to observe how this user has been using CPU over time and figure out whether the CPU usage of that user remains consistently high; if so, it could mean that that transactions executed by that user require 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 the transactions of this user 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 users, you can accurately identify that user who is consuming the maximum memory. If the memory usage of this user has been abnormally high consistently, it could indicate that the user is typically running memory-intensive transactions 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 transactions of this user 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 transactions of this user in the last measure period. MB
WPRestarts Indicates the number of work process restarts caused by transactions of this user 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 user 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 transactions executed by a user in the last measurement period and reports the highest response time.

Use the detailed diagnosis of this measure to identify the top 3 transactions executed by this user with highest response times. This leads you to the probable cause for delay in the execution of this 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.

AvgUserRespTime Indicates the total response time per transaction of this user 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 users to identify the user who is experiencing the maximum slowness. 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 the user transactions 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 a transaction of this user. 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 transactions of this user. Seconds/transaction
AvgRespTime Indicates the average response time of a transaction of this user 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 a transaction of this user. 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 the transactions of this user 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 for a transaction of this user 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 a transaction of this user 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 transactions of this user 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 spent performing enqueue operations for a transaction of this user. 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 spent waiting for RFC calls to get executed in a transaction of this user. 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 that have been performed by this user in the last measurement period. Number Using this measure, the load created by this user at the transaction invocation level can be determined.
NewInvocations Indicates the number of new invocations that are made by this user in the last measurement period. Number Use detailed diagnosis of this measure to findout the exact invocation timestamp, program, terminal and other details for first transaction step of each new invocation.