performance tools

[Former Member]

Hi,

can anybody give the tools through which we can check the performance for a particular progarm other than SE30 & ST05.

Thanks & Regards,

Sri

[anversha_s]

hi,

SE30 - gives you a run time analysis and points out the issues more at design time.

ST05 - Is the most useful if you want to track time taken for execution of each of the sections.

SM50 - Will give you a work process overview, not sure at a program level how can it help you.

Some times you will have to use a combination of SE30 and ST05.

I would like to use St05 personally.

http://help.sap.com/saphelp_47x200/helpdata/en/f2/31adaa810c11d288ec0000e8200722/frameset.htm

rgds

Anver

[Former Member]

SE30 - gives you a run time analysis and points out the issues more at design time.

ST05 - Is the most useful if you want to track time taken for execution of each of the sections.

SM50 - Will give you a work process overview, not sure at a program level how can it help you.

[Former Member]

Hi Basina,

go through this link

http://www.sapbrain.com/ARTICLES/TECHNICAL/optimization/optimization.html#For%20all%20entries

Thanks

Vikranth Khimavath

[Former Member]

SE30 - gives you a run time analysis and points out the issues more at design time.

ST05 - Is the most useful if you want to track time taken for execution of each of the sections.

SM50 - Will give you a work process overview, not sure at a program level how can it help you.

[Former Member]

HI,

ST02 --> Memory management

ST03 --> Dialog Service

OS06 --> Operating System

SCI --> Code Inspector

Regards

Sudheer

[Former Member]

Sudheer,

Thank you for your response,And one more thing what is the use of load balancing in ABAP,which is also a performance tool?

[Former Member]

SAP Load Balancing

The benefit of segregating user groups by line-of-business (using logon groups) is related to the point that groups of users (like SD users or HR users, for example) tend to use the same sets of data. They (generally) work with the same groups of tables and hit the same indexes using the same programs (transactions).

So, if you can group all of the users hitting the same tables, onto (or one set of) App server(s), then you can tune the App server buffers to a much greater extent. If the FI users (generally) never hit against the HR tables then the App servers in the FI group don't (generally) have to buffer any HR data. That leaves you free to make memory and buffer adjustments to a more drastic extent, because you don't have to worry (as much) about screwing the HR users (as an example), when you're adjusting the FI server group.

So, (in opinion only) you should start with a buffer hit ratio analysis / DB table & index access analysis (by user group) to see where you would get the best benefit from this kind of setup. If you don't have this kind of info, then creating logon groups by line-of-business may have no benefit (or worst case, may make performance degrade for the group with the highest load %). You need some historical information to base your decision on, for how to best split the users up.

You may find that 50% of the load is from the SD users and so you may need one group for them (with 3 App servers in it) and one other group for everyone else (with the other 3).

The logon group(s) will have to be referenced by SAP GUI, so SAP GUI (or saplogon.ini + maybe the services file, only) will have to change to accomodate any new groups you create in SMLG. Also consider that there's variables for time-of-day (load varies by time-of-day) and op-mode switches (resources vary by op-mode).

[Former Member]

Chandrasekhar,

Thank you very much for your valuable answer.