Active Transactions Test

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. 

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. 

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 PRIV mode heap memory and the Extended memory 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.

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 Extended memory measure indicates how each transaction 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 PRIV mode heap memory measure for a transaction therefore indicates that transactions of that type 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 transaction is 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.

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.

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.

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 GUI time, GUI Net time, Server response time, Processing time, Dispatcher wait time, Load and generation time, Roll time, Database request time, Lock time, and RFC time 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.

This measure is used by the BASIS administrators for comparing the response time across all the transaction steps executed by this transaction to determine which step is taking longer duration for execution.

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.

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. 

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.

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 dispatcher wait time.

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 Total response time measure. Higher values are indicative of performance problems. One common cause of such performance problems may be insufficient work processes.

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. 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.

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 this 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.

When data is read or changed in the database, 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 Database request time 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 contention experienced by the physical disks can also affect this time.

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 Lock time 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 Lock time 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.

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.

Ideally, the value of this measure is preferred to be low. A high value indicates high load on the transaction level.