How to check SAP Performance | Quick checks

We already shared SAP Performance Tuning in very detailed steps in the post SAP Performance Tuning. Now we are sharing the quick checks. I hope it will help you also.

Yes, there are many things to check and lot of things to be considered before we are going ahead with tuning part. In this post I would like to share a quick protocol on SAP Performance issues and troubleshooting.

Short introduction on basic components which we are going to use commonly. 

Response Time: Time taken by the user request from dispatcher to GUI

Wait Time: Work processes request is waiting in dispatcher Queue

Roll –In: User context data moves from the roll area to work process

Roll –Out: process of user context data from the work process to Roll area

Roll –wait Time: Time b/w roll in and roll out

Load Time: Time of Loading the report from the database to buffer

DB request Time: Time of retrieving/insert the report from/to the data base

CPU time: Time of executing report logic in CPU

Processing Time: Report or program executing time

Below is the summary as how to check the SAP performance issues:

 Standard threshold values for better SAP Performance

Component	Threshold value
Response Time	< 1200 ms
Wait Time	10% of Average Response Time
Roll –wait Time	200 ms
Load Time	10% of Average Response Time
DB request Time	40% of Average Response Time – Wait Time
CPU time	40% of Average Response Time – Wait Time
processing Time	Not much larger than CPU Time

 SAP Performance Problems and Possible Reasons

Problem	Possible Reason
Large Wait Time	Problem with work process sizing
Large Roll –wait Time	Can be a problem with network and RFC connections
Large Load Time	Program (PXA) and Screen (CUA) buffers are too small
Large DB request Time	Can be a problem with Expensive SQL statements, missing indexes ,CPU/Memory bottle necks and DB server
Large CPU time	Can be a problem with processing large tables and frequently accessing R/3 buffers
Large processing Time	CPU bottle necks, Net work problem and common problems

• If single user or single transaction getting this (large response time) performance problem, we need to tune the program which is causing large response time.                
• From ST03, the average response time for dialog-step should not be more than 1000 ms or 1200 ms.                                                                                                                 
• We can Check for the top programs which are causing high data base request time and programs with high CPU time, mainly we concentrate on customized programs             

• If the average DB request time is more than 500 ms, It can problem with missing indexes on tables and expensive SQL statements                                                            
• We can check for missing indexes in DB02 (detail analysis-missing indexes), if we find any missing indexes then we have to re-create the indexes for proper fields.
• And also Check the expensive SQL statements in St04,which are taking High disk reads(> 5% of total physical reads), High buffer gets/misses(> 5% of total reads) monitoring (detailed analysis menu-SQL request tab),if we got any expensive SQL statement ,we need to optimize that SQl statement by ABAP‘ers                                        
• If the CPU time is greater than 400 ms, It can problem with wrong logic of the ABAP program
• We can analyze the time consuming transaction using STAT (ie.,ABAP: RSSTAT30) and request ABAPers to make correction of wrong logic or reprogram.
• If all transactions are getting the (large response time) performance problem we need to analyze the programs which are causing large Wait Time, large roll- wait time, and large load time, large DB request time, large CPU time and large processing time.

If the average wait time is more than 50 ms

• It can problem with long running jobs.
• We can identify the long running jobs by using SM50 or SM66 and tune that long running job or terminate them.
• Work processes are blocked by long running reports, this problem occurring frequently we need to increase the work processes.
• The average number of free work processes available in the system should be sufficiently to ensure that user‘s queries are processed without delay
• If user starts the programs such as reports with very long response times, the affected work processes may be occupied for several minutes. This means that number of remaining work processes is not sufficient to process the queries of other users, which could cause wait times.

If the average DB request time is more than 500 ms

• It can be a problem with missing indexes on tables and expensive SQL statements
• We can check for missing indexes in DB02, if we find any missing indexes and create the indexes for proper fields.
• Also Check the expensive SQL statements in St04,which are taking High disk reads, High buffer gets/misses monitoring (detailed analysis menu-SQL request tab),if we got any expensive SQL statement ,we need to optimize that SQL statement by ABAP‘ers.
• Check and update CBO statistics (DB21).

If the CPU time is greater than 400 ms

• It can be a problem with wrong logic of the ABAP program.
• We can analyze the time-consuming transaction using STAT (ie.,ABAP: RSSTAT30). Than request ABAPers to make correction of wrong logic or reprogram.

If the Load time is greater than 10 ms

• It can be a problem with Program (PXA) and Screen (CUA) buffers are too small
• From ST02, We can check for the buffer quality ,it should be more than 90%,If it is less than 90%
• We can check for swaps on buffer, swaps should be in red colour and not more than 5000 swaps day, if we getting more swaps on buffers
• We need to increase program and screen buffer sizes: Program (PXA) buffer: This buffer stores the compiled executable version of the ABAP programs, also known as program loads. abap/buffersize. Screen (CUA) buffer: This buffer stores menu data, buttons and related SAPGui functionality-rsdb/cua/buffersize)

If the Roll wait time is greater than 200 ms

• There could be a problem with RFC connections or network communication
• From ST03 -We can check the average RFC + CPIC time this time indicates the time for establishing an RFC connection.
• This average RFC time should be less than 10 ms.

If the Processing time is greater than CPU time

• Can be a problem with CPU bottle necks and network problems
• From ST06, we can check the CPU idle %, if high CPU loads (the CPU Idle average per hour is less than 40%, if it is more than 40% can be a problem with logic of the current executing program.
• Then we can analyze the program which is causing top CPU TIME by using STAT (ie.,ABAP: RSSTAT30).
• And also we can analyze the Top CPU processes( ST06)
• If work processes causing high CPU load, We can analyze the time-consuming transaction using STAT (ie.,ABAP: RSSTAT30).If external processes causing high CPU load, we need to terminate the external processes
• We can check the LAN communication from ST06 (detail analysis menu –check by ping tab).