Active UsersTest

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 Active Users 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?

Target of the test : A SAP ABAP instance

Agent deploying the test : An internal/remote agent

Outputs of the test : One set of results for every user who is currently logged into the SAP ABAP system.

Configurable parameters for the test
Parameter Description

Test Period

How often should the test be executed

Host

Host name of the server for which the test is to be configured.

PortNo

Enter the port to which the specified host listens.

ClientName

Specify the ID of the client system as what the eG agent will be connecting to the SAP ABAP instance. To know how to determine the client ID to use, follow the instructions provided in Determining the Client ID/Name for the eG Agent to Connect to the SAP ABAP Instance.

SAPUser

Typically, to connect to a SAP ABAP instance and run tests, the eG agent requires the permissions of a SAP user who has been assigned with certain authorization objects. Ideally, you will have to create a new user role on the SAP ABAP instance for this purpose, associate the above-mentioned authorization objects with that role, and assign the new role to an existing SAP user. The procedure for the same has been provided in Creating a New User Role for Monitoring and Assigning it to a SAP User. Once the new role is assigned to a SAP user, specify the name of this user against SAPUser.

Password

The password of the specified SAPUser.

Confirm Password

Confirm the password by retyping it here.

SysNo

An indicator of the TCP/IP port at which the SAP server listens. For example, for a server that listens at port 3200, the SysNo will be ‘00’. Similarly, if the SAP server port is 3201, the SysNo will have to be specified as ‘01’. Therefore, in the SysNo text box specify the system number of the SAP server with which the specified client communicates. To know the system number for the ABAP server being monitored, follow the procedure detailed in Identifying the SAP Router String and System Number.

Router

If the SAP client with the specified ClientName exists in a network external to the SAP server, then a router will be used to enable the server-client communication. In such a case, specify the router string of the router in the Router text box. If both the client and the server exist in the same network, then specify ‘none’ against the Router text box. To know what is the SAP Router string for the ABAP server being monitored, follow the procedure detailed in Identifying the SAP Router String and System Number.

InstanceName

This is set to none by default. This implies that the eG agent automatically discovers the instance name at run time. 

Timeout

Indicate the duration (in seconds) for which this test should wait for a response from the SAP ABAP instance. By default, this is set to 120 seconds.

JCO Version

The eG agent uses the SAP JCO library to connect to the SAP ABAP system and pull out metrics. To enable the eG agent to make this connection and query the metrics, you need to specify the version of the SAP JCO library that the agent needs to use. For instance, to instruct the eG agent to use JCO v2.1.19, it would suffice if you specify the ‘major version number’ alone against JCO Version – in the case of this example, this will be 2.x. Note that if you have downloaded the SAP JCO CONNECTOR files for SAP JCO version 3 from the SAP market place (as instructed by Downloading the SAP JCO Connector files Required for Monitoring ), then the JCO Version configuration should be 3.x. 

Maximum Steps

To report workload metrics, the eG agent will have to typically analyze numerous dialog steps of activity on the SAP ABAP system. To reduce the stress on the eG agent, you can limit the number of dialog steps the eG agent needs to process in order to make a fair assessment of the workload and the processing ability of the ABAP system. This limit can be specified against maximum steps. By default, this limit is set to 5000.

Include Users

By default, this test monitors only those users who are currently logged into the SAP ABAP system. This is why, this parameter is set to none by default. If you want a few specific users to be monitored regardless of whether they are logged in or not, specify the names of those users as a comma-separated list against this parameter. If this is done, then such users alone will be monitored irrespective of their login status, while all other users will be monitored only if they are currently logged in.

IsPassive

If the value chosen is Yes, then the server under consideration is a passive server in a SAP ABAP INSTANCE cluster. No alerts will be generated if the server is not running. Measures will be reported as “Not applicable” by the agent if the server is not up.

Detailed Diagnosis

To make diagnosis more efficient and accurate, the eG Enterprise suite embeds an optional detailed diagnostic capability. With this capability, the eG agents can be configured to run detailed, more elaborate tests as and when specific problems are detected. To enable the detailed diagnosis capability of this test for a particular server, choose the On option. To disable the capability, click on the Off option.

The option to selectively enable/disable the detailed diagnosis capability will be available only if the following conditions are fulfilled:

  • The eG manager license should allow the detailed diagnosis capability
  • Both the normal and abnormal frequencies configured for the detailed diagnosis measures should not be 0.
Measurements made by the test
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. 

CPU utilization

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. 

Total memory

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

PRIV mode heap memory

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

Extended memory

Indicates the maximum extended memory used by transactions of this user in the last measure period.

MB

 

Work process restarts

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.

Maximum response time of a step

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.

Total response time

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

Average step response time

Indicates the average response time of a transaction step executed by this user 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 this user to determine which step is taking longer duration for execution.

GUI time

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.

GUI Net time

Indicates the average front end net time taken for the first and last steps of transactions of this user.

Seconds/transaction

Server response time

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. 

Processing time

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.

Dispatcher wait time

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

Load and generation time

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

Roll time

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.

Database request time

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 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 contentions experienced by the physical disks can also affect this time.

Lock time

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

RFC time

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.

New invocations

Indicates the number of new invocations that are made by this user 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 find out the exact invocation timestamp, program, terminal and other details for first transaction step of each new invocation.