cancel
Showing results for 
Search instead for 
Did you mean: 

ST03N?

Former Member
0 Kudos

Hi,

Perhaps the question you will seem stupid, but in the ST03N for the value of response the Time I must consider the " total response Time (s)" or the " average response Time (ms)?

I find complicated enough to read this transaction!

Regards

Accepted Solutions (0)

Answers (5)

Answers (5)

Former Member
0 Kudos

The correct response to your question is that both are of great value.

The average response time is used as a banchmark of how well a transaction performs and can be used to see if performance gets worse by graphing this over time. However the statistic is only useful when the same users run the same transaction in the same way every day. PA30 is a good example, very high usage in many systems but very variable performance from day to day. The statistic in itself is of very little use until it is used as a comarison tool with the other parameters like average DB time and average processing time... even then it needs to be treated with caution.

The total response time however I find far more useful. It tells me how much value it is to tune this transaction. If the total reponse time of a transaction is a very small percentage of the overall total reponse time of all transactions then any value I give by tuning it is to the users of that transaction.

Of all the Total times I find the total DB response time the most useful. DB response is often the real reason for general poor performance (as well as paging) and whatever transactions are using the most total DB response time will be the most value to tune.

ST03 is good for trending but I find RZ20/RZ23N far far better tools unless looking directly at a transaction. Even then I go for STAD before ST03.

Please also remember that ST03 and STAD use large amounts of memory and if a performance problem is already happening then you just may make it worse, especially if a few Basis people start looking at it. Correct use of RZ20 is a much better approach (and can do your J2EE performance as well if you know what you are doing)

I might also point out that some of the values given above are far too high/low or restrictive, how can you say you have performance problems if you have a response time greater than 1000 ms, what if the only transaction run at the time took 4 minutes to run and that was expected.....Performance values can only be safely judged against a set of benchmarks set when the system is running well.... apart from the standard response time that is

Edited by: Graham Newport on Jun 13, 2008 12:54 AM

Former Member
0 Kudos

Hi Graham,

Excellent post here. I've always sais in my company that I need a permanent access to the production system to know it when it works correctly.

As you said perfectly, you have to know the usual response times in YOUR system to be able to judge if you get a performance problem.

Measurements have no absolute meanings, it's the comparaisons that matter.

Regards,

Olivier

Former Member
0 Kudos

Cheers,

I teach ADM315 and I have come to learn that you tell people all this stuff but if they do not use it, they forget it.

I really try to encourage the checking of the standard dialog response time as in fact that is a measurement of poor performance of significant performance spikes... it is the true measurement

Former Member
0 Kudos

Therefore as an example I carry out a control on today if for a TCODE custom I have:

Average Resp.T. = 9.219,0

CPU T.= 2.938,0

DB T. = 7.976,0

I have or not a problem on the DB and what can make?

Regards.

pavan_kumargali
Explorer
0 Kudos

Hi Diego Garofalo ,

As above folks told Avg. Response time and Total Response time, both has it's own importance. But for the performance tuning case, generally we need to consider Avg. Response time.

To give you overview of ST03N transaction,

Let me add some key steps to analyze performance of your system (e.g. R/3 system).

Start with the transaction ST03N.

*St03N:* Try to find the Avg. Response time for the Dialog task for all the servers and instances.

SAP Threshold for this is 1000ms. If you see >1000ms, which means your system is having some issues and some tuning is needed.

The parts of response time are:

DB time (SAP threshold is 40% of Avg. Response time)

CPU time (SAP threshold is 40% of Avg. Response time)

Wait time (SAP threshold is 10% of Avg. Response time)

GUI time (200ms.)

Roll wait time (200ms.)

Roll in time(20ms.)

The other times are which are not direclty part of response time:

Processing time (<2*CPU time)

http://help.sap.com/erp2005ehp_03/helpdata/EN/c4/3a6af1505211d189550000e829fbbd/frameset.htm_

1. DB time is high, which mean above SAP threshold:

ST04 (database monitor):

Lookinto Database buffer quality (SAP Threshold is 94%)

If this Database buffer quality is less than the SAP threshold try to increase database buffer cache size.

Shared pool size (generally from 600MB to 2GB depending on the size of the database)

In the same ST04 screen look for user/recursivecalls, if this factor is >20 then we can say thre are some expensive SQL statements which in need of tune. Analyse the top expensive statements. possible reasons of expensive SQLs are i) incorrect index access (Solution is create new index or reorganize the index)

ii) high table size (Soluiton is archiving some of the old entries)

2. If CPU time is high, which mean above SAP threshold:

ST06 (OS monitor):

Go to Detailed Analysis Menu--> Top CPU , check existence of Non-SAP (external) programs by sorting by CPU time.

Try to run these external programs in offline hours.

ST02 (Buffer Monitor):

Check for any swapping happening in all the buffers. If you observe high swapping for any buffer, increase the size of the buffer.

Here program buffer (PXA) is important buffer.

3. If Wait time is high, which mean above SAP threshold:

SM50 (Workprocess Monitor):

Look for all the configured work processes are in Waiting or Running state.

If all the wotk processes are running state, then increase the number of Dialog work processes.

SM66 (Global work process Monitor):

This monitor will help to analyse the total work processes configured in all the servers and instances.

4. If GUI time is high, which mean above SAP threshold:

ST06> Detailed Analysis Memu> LAN check by ping (4096 bytes for all the presentation servers)

This will help to findout network performance. If you see high Avg. time or Loss time for any presentation servers from the result, which means there are some settings in need of change for that presentation server.

SE38-->execute PROFGEN_CORR_REPORT_5 report.

from the output check if any user assigned with >1000 user menu nodes.

SAP threshold is 1000 menu nodes.

5. If Roll Wait time is high, which mean above SAP threshold:

Please review SAP Notes 8963 and 99584. Roll wait time with a high value is a first indication for a slow network between the GUI and the CRM instance. Please check connections between the frontend and your servers. You can monitor relatively high average roll wait time, high average frontend network time per dialog in transaction ST03N. Please check your network with network vendor.

Specifically, check the network between application servers and fronts by running NIPING test as per SAP Note 500235.

If you need any further information feel free to reply me.

Thanks and Regards,

Pavan Kumar Gali.

Former Member
0 Kudos

Hi,

Yes it is correct.

Always consider the Average response time, when u are analyzing anything in st03n.

Thanks,

Kiran

Former Member
0 Kudos

Thanks for your answer, but which it is the difference between the " totale" and " average"?

Reagards.

Former Member
0 Kudos

Hi,

Total response time is the time taken for all the dailog steps and the average response time is the time taken for one dialog step.

If you multiply avg. response time and dialog steps, it will be equal to total response time.

So instead of analyzing using total response time, it is good to analyze using avg response time.

If you feel that this helps, kindly rewars points.

Thanks,

Kiran

Former Member
0 Kudos

Hi,

Total response time gives you the importance of a transaction or report load wise.

Average response time gives you the performance information.

But the 2 infos are linked.

If you have a very bad average monthly response time for a transaction but its Total response time is very low, it means that it is not used often and the performance problem is not very important.

So both informations are useful.

Regards,

Olivier

Former Member
0 Kudos

Hi Diego,

Generally, I consider "Average Response Time". This is because, almost all the benchmarks are calculating on average times.

Besy regards,

Orkun Gedik