cancel
Showing results for 
Search instead for 
Did you mean: 

Understanding High Processing Time (ST03N)

former_member229542
Active Participant
0 Kudos

Hi guys.

After reviewing a couple of long running jobs, i came up with this one which has odd values

# Calls 600.000

DB Records 58.829

Seq Records 112.107

Sequential reads 378.211

Direct Reads 26.690

Accesses 162.963

CPU Time    74031    ms

CPIC-/RFC Time (ms)    0    ms

response time (ms)    21296994    ms

Waiting Time (ms)    0    ms

Processing time (ms) 21116018 ms

Load time (ms) 13 ms

Generation time 0 ms

Roll-In + wait time (ms) 1 ms

Database time 180962 ms

# Views Datenbankproz. 0

Total time DB Procedures 0 ms

Off Time ms) 0 ms

Block number 0 ms

Report Load time 8 ms

Load time screen (ms) 0 ms

CUA load time (ms) 5 ms

Roll-in operations 14

Roll-out processes, 12

Roll-In-Time (ms) 1 ms

Roll-out time (ms) 1 ms

Roll Wait Time (ms) 0 ms

As you can see, 99% of Response Time, comes from Processing Time, but there is little CPU Time & Database time, and none waiting.

Does it means CPU Bottlenecks? How can you breakdown Processing Time values to determine what is causing this?

Which notes are helpful to understand this? I came with these notes but any explanation would be appreciated.

Note 1014072 - High response time in transaction STAD or ST03 or ST03Nb

Note 8963 - Definition of SAP response time/CPU time

Note 376148 - Response times without GUI time

Note 805934 - FAQ: Database time

Note 110686 - Different response times ST03, ST07

Thanks a lot for you help.

Accepted Solutions (1)

Accepted Solutions (1)

former_member229542
Active Participant
0 Kudos

Thanks for the help understanding this concept

Answers (2)

Answers (2)

Former Member
0 Kudos

Hi Martin,

First of all, note 8963 says: "Processing time = response time".

And Performance Analysis in SAP is a very very big area.

I'm more interested in this figure: Sequential reads 378.211 Direct Reads 26.690

Mainly, Direct Read refers to accesses in which a maximum of one line is returned by the database, otherwise Sequential Read refers to all other read database accesses, in which there may be more than one line returned.

In case of Sequential Read, when you perform a trace on these queries you will see that index is used in most cases. However Direct Read have better performance than Sequential.

So my idea is to check what the job really does, which tables are being read sequentially (SM50 while the job is running), and which SQL statements might be expensive (ST05, execution plan).

Then you can check if those tables are being read using indexes (if not, maybe create new index), also check if the daily update statistics of your database is running (SM13), also check if buffers are not "red" (ST02), and maybe have an ABAP-er recheck the SQL-statements to optimize them.

It could also helpful to check the database area (parameters) as well, but you need to check the figures on ST04 to be able to analyze this.

So again, this is only my tips to check with the info you are providing, and not all conclusive by any means.

I hope this will help you.

Regards,

Andre

Former Member
0 Kudos

So my idea is to check what the job really does

That would be my plan too, i don't think this is database time (which is the case very often). This is what i would check the next time the job is running.

- SM50: check if there is a stop reason, which program and/or table is used, are all workprocesses running

- OS processes: check top or task manager

- OS resources, CPU, disk, network

- check SM21, dev_wX, dev_disp, dev_rd for errors, timeouts and the like

( - use the debugger several times to check which part of code is using the most time ) <- don't do this if you don't know the debugger

Cheers Michael

former_member256962
Participant
0 Kudos

Hello Mr.Wahjudi,

fyi,,Note 8963 never said "Processing time = response time"... It mentions few metrics which has to be deducted from response time while calculating "Processing time".

Processing time = response time

"- " Wait time the dispatcher is waiting for a free

  work process (= dispatcher queue).

"-" Load/generating time for loading/generating

  screens, ABAP programs, and CUA

  elements (not in presentation).

"-" DB time for accessing and waiting for the data-

  base interface and, therefore, for the

  underlying database.

"-" Roll-in time for the roll-in of the roll area

  context of a dialog step and possibly

  for a dialog step that is waiting for RFCs

  (as of Rel. 4.0A, also called 'roll wait

  time', see below for more information).

"-" Enqueue time for setting a logical SAP enqueue.

"-" DB procedure time time for processing DB procedures

  in the database (as of Rel. 4.6C; for

  example, in liveCache).

Thanks & Regards,

Ravindran D'

Sriram2009
Active Contributor
0 Kudos

Hi Martin

Could you share the OS /DB info and also during those peaks check the ST02 status?

Thanks

Ram