SAP R/3 Workload Analysis

Architecture
To complete the logon process, the presentation server connects with a dispatcher.
When the user tries to run a transaction, the user's request comes from the
presentation server to the dispatcher and is put into the local wait queue.
When the dispatcher recognizes that a work process is available, the user's request
is taken from the wait queue and sent to the work process
When a user is dispatched to a work process, "user context" data the user's logon
attributes, authorizations, and other relevant information is transferred from the
roll buffer, extended memor!, or the roll file into the work process. This transfer
"b! cop!ing or mapping, as appropriate# of user context data into work process
memor! is the mechanism known as a "roll in". Transaction processing then
begins.
$f data from the database is required to support transaction processing, a request
for data is sent to the database interface, which in turn sends a request through the
network to retrieve the information from the database.
When it receives the request, the database searches its shared memor! buffers. $f
the data is found, it is sent back to the work process. $f the data is not found, it is
loaded from the disk into the shared memor! buffers.
%fter being located, the data is taken from the shared memor! buffers and sent
back across the network to the requesting database interface. Transaction
processing resumes.
&efore accessing the database service, the database interface searches for the data
in the '() buffers. $f the data is found, it is rela!ed back to the work process where
processing resumes. $f the data is not found, the database interface sends a request
over the network to retrieve the information from the database
$f the data loaded from the database is eligible for '() buffering, it is placed in the
'() buffers. Transaction processing resumes.
When transaction processing is completed, the dispatcher is notified of its
completion. The results of the transaction are then sent back to the presentation
server.
%fter the transaction finishes and the work process is no longer required, the user
context data is rolled out of the work process.
*+, time is the amount of time during which a particular work process has active
control of the central processing unit "*+,#.

Performance Analysis - Key transaction for Performance monitoring in R/3
Work +rocess ./01(./22
3perating s!stem monitoring .T12
Workload anal!sis, use the Workload /onitor "transaction ST03 or ST03N#.
4atabase monitoring .T15
.etup and buffer .T16
Workload time statistics include7
Response time in milliseconds7 .tarts when a user request enters the dispatcher
queue8 ends when the next screen is returned to the user. The response time does
not include the time to transfer from the screen to the front end.
Wait time in milliseconds7 This is the time a user request sits in the dispatcher
queue. $t starts when user request is entered in the dispatcher queue8 and ends
when the request starts being processed.
Roll-in time in milliseconds7 The amount of time needed to roll user context
information into the work process.
Load time in milliseconds7 The time needed to load from the database and
generate ob9ects like %&%+ source code, *,%, and screen information.
Processing time7 This is equivalent to response time minus the sum of wait time,
database request time, load time, roll time, and enqueue time.
Dataase re!uest time7 .tarts when a database request is put through to the
database interface8 ends when the database interface has delivered the result.
"P# time in milliseconds7 This is the *+, time used b! the '() work process
$f a problem is detected, the data in the Workload /onitor "Transaction .T1):# can be
used as follows to identif! the area of the s!stem where the problem is located.
;irst check for general performance problems affecting all transactions. <ood general
performance is normall! indicated b!7
Wait time = >1? response time
/ain menu "choose Transaction Profile# = >11 ms
$n the Workload /onitor, the following values normall! indicate good
performance7
%verage roll-in time = 61 ms
%verage roll wait time = 611 ms
%verage load "and generation# time = >1 ? of response time "=01 ms#
%verage database request time = 51 ? of "response time - wait time#
%verage *+, time = 51 ? of "response time - wait time#
%verage *+, time :ot much less than processing time
%verage response time - 4epends on customer requirements there is no general rule
@arge roll wait time - *ommunication problem with <,$
@arge load time +rogram buffer, *,% buffer or screen buffer too small
@arge 4& time *+, (mem bottleneck on 4& server, Axpensive .B@ statement, missing
indexes, small buffer, missing statistics.
$; wait time C>1?
Digh database time C51? "response time wait time# %nal!ze database
+rocessing time C *+,time E6 %nal!ze hardware
@oad time C01 ms %nal!ze '() memor! config " program buffer too small#
'oll in ( roll out time C61 ms - %nal!ze '() mem config "extended mem or roll
buffer#
Analysis of S$%& / S$''
To displa! a snapshot of the current activities on the instance !ou are logged on to,
use the Work +rocess /onitor. *all transaction ./01, or, from the '() initial
screen, choose Tools CC %dministration CC /onitor CC .!stem monitoring CC
+rocess overview.
The information displa!ed includes7
- T!pe of work process
- :ame of the %&%+ program running
- 3perating s!stem +$4 number
- *lient being used
- :ame of the 9ob executing
- *urrent action
- :umber of detected errors in the work process
- Table being utilized
- .emaphore resource being used
- *+, accumulation
- Time in process accumulation
- ,ser holding the resource
$f all work processes are being blocked b! long running transactions, the above
information is also available on operating s!stem level b! using program dpmon.
$n an '() .!stem with more than one instance, !ou can access a global work
process overview using transaction ./22.
%nal!sis work flow .
Work process in status FrunningG and %ction 4irect 'ead, .equential read, $nsert, ,pdate,
4elete, *ommit. %nal!ze 4atabase
Work process in status FrunningG and %ction load program +rogram buffer too small
Work process in status FrunningG and %ction rollin (rollout Axtended memor! or roll
buffer anal!sis needed.
Work process in status FstoppedG and reason FprivG 4etail anal!sis for memor!, issue
with extended memor! or roll buffer.
Work process in status FstoppedG and reason FcpicG- +roblem with *+$* connection. The
remote s!stemGs all work process ma! be in use.
Analysis for S(&' )*perating System monitoring+
$f the idle *+, is indicated as being less than 61 ?, there is a *+, bottleneck. $n an
optimal configuration, more than )0 ? *+, capacit! is idle
$f there is a *+, bottleneck7
>. $f possible, redistribute load to other servers.
6. To find out which processes are using the most *+,, in the 3perating .!stem /onitor
choose Detail analysis menu CC Top CPU processes. $f the processes have high *+,
utilization, proceed as follows7
;or '() work processes ""dispHwork"#7 ,sing the process $4 indicated in Top
CPU processes, identif! the corresponding program name and user name in the
Work +rocess 3verview "transaction SM50#.
;or database processes7 $dentif! corresponding long running .B@ statements in
the 4atabase +rocess /onitor. To access this monitor, call transaction ST04
"4atabase 3verview#, and choose Detail analysis menu. Then choose, for
example, Oracle Session.
;or external processes, find out whether the process can be stopped or
redistributed.
%mount of memor! indicated beside Physical memory availale! *ompare this figure
with the paging rate. To obtain the paging rate, double-click Pa"es in#s. The paging rates
for the last 65 hours are displa!ed in the columns Pa"e$ in %&#h' and Pa"e$ out %&#h'!
$f 61? of the total amount of ph!sical memor! is greater than the amounts indicated in
these columns, !ou can normall! be sure there is no memor! bottleneck!
$f there is a memor! bottleneck7
>. $f possible, redistribute load to other servers.
6. *heck the size of the file s!stem cache .ee .%+ :ote IJ5KJ in .%+:et. $f necessar!,
reduce file s!stem cache to = >1? of the total ph!sical memor!.
). To identif! users and their programs with a high memor! consumption, call the /ode
@ist for the extended memor!. To do this, in the .etups(Tune &uffers monitor "transaction
ST0(#, choose 4etail anal!sis menu CC S)P memory CC Mo$e *ist.