Logging in:
While logging in, the presentation server connects with the dispatcher for allocating the work processes. When a user tries to run a transaction, the user’s request comes from the presentation server to the dispatcher is put into the local wait queue. When the dispatcher recognizes that the work process is free, it allocates the process to the user’s request taken from the wait queue.
‘Wait time: in milliseconds.’
This is the time when the user’s request sits in the dispatcher queue for allocation of work process. It starts when the user’s request is entered in the dispatcher queue and ends when a process is allocated for the request waiting in the queue.
‘User context data’
When a user is dispatched to a work process, the details such as user’s logon attributes, authorizations and other relevant information is transferred from the roll memory, extended memory or the roll file in to the work process. This transfer of user context data into work process is called as ‘Roll in’.
If data from the database is needed to support transaction processing, then the request for data is sent to the database interface, which in turn sends a request through the network to retrieve information from the database.
When a request is received, the database searches its shared memory buffers. If it is found, it is sent back to the work process. If the data is not found, then it is loaded from the disk into the shared memory buffers. After being located, the data is taken from the shared memory buffers and sent back across the network to the requesting database interface.
When transaction processing is completed, the dispatcher is notified of its completion. The work process then is no longer required; the user context data is rolled out of the work process.
CPU time
CPU time is the amount of time during which a particular work process has active control of the central processing unit.
Response time in milliseconds
Starts when a user request enters the dispatcher queue; ends when the next screen is returned to the user. The response time does not include the time to transfer from the screen to front end.
Roll in time in milliseconds
The amount of time needed to roll user context information into the work process.
Load time in milliseconds
The time needed to load from the database and generate objects like ABAP Source code, CUA and screen information.
Processing time
This is equivalent to response time minus sum of wait time, database request time, load time, roll time and enqueue time.
Database request time
Starts when a database request is put through the database interface; ends when the database interface has delivered the result.
General performance indicating factors: factors indicating good performance.
Wait time < 10% of response time.
Average roll in time < 20 milliseconds.
Average roll wait time < 200 ms.
Average load (& generation time) < 10% of response time(<50 ms)
Average database request time < 40% of (response time – wait time)
Average CPU time < 40% of (response time – wait time)
Average CPU time is not much less than processing time.
Average response time – Depends on customer requirements there is no general rule.
Problems in the above factors and reasons for their problems
Large roll – wait time -> Communication problem with GUI or external system
Large load time -> Program buffer, CUA buffer or screen buffer too small
Large database request times -> CPU/ memory bottleneck on database server, network problems, expensive SQL statements, database locks missing indexes, missing statistics, small buffers
Large CPU times -> Expensive ABAP processing, for example, processing large tables, frequent accessing of R/3 buffers
Processing time much larger than CPU time -> CPU bottlenecks, network problems, communication problems
R/3 Workload monitor (ST03N)
Problem: Wait time > 10% of response time!
Result: General performance problem.
Problem: High database time: database time > 40% of(response time – wait time)
Solution: Detailed analysis of the database.
Problem: Processing time > CPU time * 2
Solution: Detailed analysis of hardware bottlenecks.
Problem: Load time > 50 ms.
Solution: Detailed analysis of R/3 memory configuration (is the program buffer too small?)
Problem: Roll wait time or GUI time > 200 ms.
Solution: Detailed analysis of interfaces and GUI communication.
In the workload monitor, choosing transaction profile enables you to find out:
- The most used transactions. Tuning these transactions creates the greatest improvements in the overall performance.
- The average response times for typical R/3 transactions.
To access the statistical record of a specific server:
Transaction : STAD after Release of 4.5
STAT before Release of 4.5
Transaction profile (Transaction ST03N) sorted by ‘Response time total’
Programs with high CPU time: CPU time > 40% (response time – wait time)
Detailed analysis with ABAP-TRACE (SE30)
Programs with high database time(database time > 40%(response time – wait time)
Detailed analysis of SQL Statements (ST05)
Problems with high GUI times (>200ms)
Solution: Network check
Workload Monitor
To display the 40 slowest dialog steps by response time, then choose Top time.
Under Goto -> profiles, you can access, for example:
Task type profile – Workload statistics according to work process type
Time profile – Workload statistics according to hour
Transaction profile – Workload statistics according to transaction
The proportion of database calls to database requests gives an indication of efficiency of table buffering. If access to information in a table is buffered in the R/3 pool buffers, then database calls to the database server are not needed and the performance is better. Thus fewer database calls result in database requests, the better.
Using transaction profile of ST03N, you find out:
Which transactions are used most? Tuning these transactions creates the greatest improvements in overall performance.
What are the average response times for typical R/3 transactions?
