Analyzing General Performance Problems

Is There a General Performance Problem?

Criteria

Users can often identify a general performance problem. You can use the workload monitor to verify users' observations and check whether response times that affect all transactions are high. The following criteria, which apply to dialog tasks, may help you decide if there is a problem:

->Dispatcher wait time > 50 ms
A long dispatcher wait time always affects all transactions. It implies that programs are too slow and are blocking work processes for lengthy periods-or that too few work processes have been configured.
->Database time > 40 % (response time minus dis[patcher wait time) and database time > 400 ms
A high database time slows performance for all transactions.
->Processing time > 2 x CPU time
High processing time slows performance for all transactions. This can be caused by a CPU bottleneck or a problem with communication between systems.
->Average response time > system-specific guideline value
Average response time for a dialog task is seen by many SAP users as the decisive criterion for acceptable performance in an SAP system. A generally accepted rule of thumb is that good performance is indicated by an average response time of one second or less. This kind of broad generalization is not always valid for all the different requirements of SAP systems. A guideline value must be defined for each individual SAP system.

Is the Performance Problem Temporary or Permanent?

Identifying temporal pattern

After verifying that there is a general performance problem, try to find out how frequently the problem occurs. The following questions may help:
->Is the problem permanent or temporary?
->Does this problem occur at regular time intervals-for example" at particular times of the day?
->Is it a nonrecurring problem?
->At what times (database time, CPU time, or processing time) does the problem occur?
->Does the problem occur following only specific system activities - for example, when background programs run on the system?
To examine these questions more closely, compare the workload statistics for recent days. In in the upper-left window in expert mode of the workload monitor, select LOAD HISTORY AND DISTRIBUTION • LOAD HISTORY • TOTAL. Compare the performance values for several days to find out if the problem only occurs on certain days

Creating time profile

Then, generate the day or time profile by selecting the TIME PROFILE analysis view in the lower left of the workload monitor window. The transaction steps and response times for all the hours in one day are presented in a day or time profile. Using the time profile, you can analyze the daily loads on the system. If you find that the average response time increases dramatically only at particular periods of high load, you can infer that the system is overloaded at these times. If the average response times are also unsatisfactory at times of low system load, the performance problem is load independent.

Dialog versus background load

Time profiles enable you to determine whether excessive background processing during periods of peak system load has a negative impact on dialog processing. To create time profiles for dialog processing and background processing, click the TASK TYPE button and select the task types DIALOG or BACKGROUND. Use the TOTAL RESPONSE TIME (S), TOTAL CPU TIME TOTAL (s), and TOTAL DB TIME TOTAL (s) fields to determine what time of day the dialog or background load occurs. These profiles enable you to determine whether excessive use of background processing during periods of peak system load has a negative impact on dialog processing. Try to ensure that the background processing load remains low during these peak periods, particularly if there are performance problems. You may also find it helpful to compare the time profile per day in the workload monitor with the time profile per day for CPU load and paging (both indicated in the operating system monitor). This comparison enables you to determine whether deteriorating response times correlate with a large CPU load or a high paging rate. If so, a temporary hardware bottleneck is indicated.

Is There a Hardware Bottleneck on Your Computer?

Check steps

A CPU bottleneck or main memory bottleneck can be detected as follows: 
1. Find out if the hourly averages for the CPU load or paging rate are large. As a rule of thumb, the risk of a hardware bottleneck is regarded as high when the hourly average of free CPU capacity (indicated as CPU IDLE) is less than 20% or the paging rate per hour exceeds 20% of the physical main memory. 
2. Check whether the large CPU load or high paging rate really does negatively affect SAP system response times. To check for a hardware bottleneck on an application server, look at the processing time. If the processing time is much greater than double the CPU time, this indicates that the work processes are waiting for CPU resources. (However, an increased processing time may have other causes. To check for a hardware bottleneck on the database server, establish whether the database time is too long. Has it increased? Compare, for example, the average database times in the daily time profile at times of high and low loads.

3. To check for a main memory bottleneck, determine whether the virtual allocated memory is significantly greater than the physical available main memory. As long as virtual allocated memory is less than 1.5 times the physical main memory, there is usually no risk of a main memory bottleneck 

Hardware bottleneck: causes

The three possible causes of a hardware bottleneck are as follows:

->Poor load distribution
The load is not optimally distributed across the servers. There may be servers with free CPU or main memory capacity. Alternatively, load distribution may become less than optimal at certain times of the day, for example, when several background processes run in parallel during periods of peak system load. You should be able to reschedule these programs to run when there is low system load .
->Individual processes cause high CPU load
Individual processes with high CPU loads may be running when there is a high system load. These can include database processes (with expensive SQL statements), SAP work processes (with programs running as background jobs), or processes external to SAP. To improve performance, you may be able to tune, reschedule, or (in the case of external processes) cancel these processes .
->Insufficient hardware capacity
If the two previously mentioned causes of hardware bottlenecks do not apply, the hardware capacity may be too small for your system load.

Is There a General Database Performance Problem?

Checking database times

A general database performance problem is indicated by increased database times. The following guideline values for dialog tasks in the workload monitor can indicate a general performance problem:
->Database time > 40% of response time minus dispatcher wait time, and database time > 400 ms
->Direct read > 2 ms
->Sequential read> 10 ms
->Logical database changes > 25 ms

Is the load Distribution Optimal?

You can detect a performance problem caused by non-optimal load distribution by comparing the CPU load and paging rates for the various servers (in the operating system monitor). You should also compare response times for the various application servers in the workload monitor.

Displaying server profile

In the workload monitor, display the server profile, which can be found in the selection tree under the following path:

LOAD HISTORY AND DISTRIBUTION • COMPARISON OF INSTANCES

Select the type of period (day, week, or month). You can then enter the desired period of analysis with the arrow keys. The server profile shows the transaction steps and related response times for each server. If there are several SAP instances on one application server, the statistics indicated for the server are the totals for all instances on that server. To obtain details on the individual servers' task types, double-click a row in the list of servers.

Dispatcher wait time

In the server profile, check the load distribution across your servers. For example, if the dispatcher wait time occurs only on one server or on a small number of servers, this implies either that too many users are working on these servers or that too few work processes are configured on these servers.

CPU time

Total CPU time (indicated as CPU TIME TOTAL) on all application servers should be roughly equal if all servers have the same CPU capacity. If you have servers with different CPU capacities, CPU times should differ accordingly. One cause of poor load distribution may be a nonoptimal configuration of logon groups or work processes.

 Database time

If the average database times (indicated as DB TIME AvG.) or the various servers differ greatly, this may indicate a network problem. You can assume that application servers are configured with the same work processes and that users on the various application servers are, on average, using the same transactions. Therefore, there is no obvious reason, other than a network problem, for the database to serve one application server slower than another application server. This argument applies only to servers that are configured with the same work processes. For background servers, update servers, or servers mainly used for reporting, the average database time will be greater than that for dialog servers.

Is There a Performance Problem Caused by SAP Memory Management?

These problems are indicated in the workload monitor as follows, and these guideline times apply to dialog tasks:
->If the program buffer, CUA buffer, or screen buffer is too small, there will be an increase in average load time (average load time > 50 ms).
->If the extended memory or roll buffer is full, the roll-in or roll-out times may increase (average roll-in or roll-out times > 20 ms).

Memory profile

You should also monitor the main memory profile. This can be found in the workload monitor under MEMORY USE STATISTICS. The memory profile shows memory usage per program. Utilization of extended memory and heap memory (EXTENDED MEMORY or PRIVATE MEMORY) are indicated.

The monitor also shows how often work processes entered PRIV mode (WORK PROCESS RESERVATIONS column) and how often a work process was restarted after its use of heap memory had exceeded the value of the parameter abap/heaplimit (RESTARTS OF WORK PROCESSES column).