By comparing the value of this measure across transactions, you can accurately identify that task type 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 transactions of a particular task type.

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

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

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.

Compare the value of this measure across task types to identify the task type that 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.

The processing time of the DIALOG task type for instance should be below twice the CPU time. The same for the UPDATE task type should be about 50% higher than that of the DIALOG task type.

For the DIALOG task type 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.

Typically, for a DIALOG task type, 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.

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.

Ideally, for the DIALOG task type, the value of this measure should be 40% of the total response time. Many factors can 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 contention experienced by the physical disks can also affect this time.

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

For a DIALOG task type typically, the locktime should be less than 5 ms. Any value higher than that would represent a problem that migh affect system stability. Network problems can also increase the value of this measure.

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.