Regarding Performance tunning...

[Former Member]

HI Experts,

can you suggest me, how exactly performance is checked.

what is the measure we considered for performance check.

what are ideals status of the performance check for a certain program.

that is, how much should be database use, abap use and the system

use in the program.

i checked my program in t-code SE30, and it is showing almost

above 90% use of database and very less use of abap and

almost no use of system.

so please tell me exactly how much it should be...

Thanks in advance.

Regard,

vijay chavan

[Former Member]

Hi,

Run Any program using SE30 (performance analysis)

Note: Click on the Tips & Tricks button from SE30 to get performance improving tips.

Using this you can improve the performance by analyzing your code part by part.

->To turn runtim analysis on within ABAP code insert the following code

SET RUN TIME ANALYZER ON.

->To turn runtim analysis off within ABAP code insert the following code

SET RUN TIME ANALYZER OFF.

->Always check the driver internal tables is not empty, while using FOR ALL ENTRIES

->Avoid for all entries in JOINS

->Try to avoid joins and use FOR ALL ENTRIES.

->Try to restrict the joins to 1 level only ie only for tables

->Avoid using Select *.

->Avoid having multiple Selects from the same table in the same object.

->Try to minimize the number of variables to save memory.

->The sequence of fields in 'where clause' must be as per primary/secondary index ( if any)

->Avoid creation of index as far as possible

->Avoid operators like <>, > , < & like % in where clause conditions

->Avoid select/select single statements in loops.

->Try to use 'binary search' in READ internal table. -->Ensure table is sorted before using BINARY SEARCH.

->Avoid using aggregate functions (SUM, MAX etc) in selects ( GROUP BY , HAVING,)

->Avoid using ORDER BY in selects

->Avoid Nested Selects

->Avoid Nested Loops of Internal Tables

->Try to use FIELD SYMBOLS.

->Try to avoid into Corresponding Fields of

->Avoid using Select Distinct, Use DELETE ADJACENT

regards,

Omkar.

[Former Member]

hi omkar,

thanks for good reply.

but i would like mostly those thing which we can use in the program

rather than what should we avoid.

i hope you got my point now.

anyway thanks for good reply..

bye..

regard,

vijay

[Former Member]

OK - try to use the primary index in SELECTs; if you can't use the primary index, try for the secondary index.

Within loops, use reads using binary searches rather than a nested loop.

Check this:

<a href="/people/rob.burbank/blog/2006/11/16/performance--what-will-kill-you-and-what-will-leave-you-with-only-a-flesh-wound">/people/rob.burbank/blog/2006/11/16/performance--what-will-kill-you-and-what-will-leave-you-with-only-a-flesh-wound</a>

Rob

[Former Member]

Hi that depends. when u are checking for a small prog. with 2 slects and 2 loops certainly DB time will ve very more and ABAP time will be less. in that case u can't do anything.

CHeck wirh Run time analysis and SQL Trace only... but finally you have to judge. mostly we will code the same program in different ways and then compare b/w them and take the best one.

[Former Member]

Hi

these are the ways of checking performance of a report

Tools for Performance Analysis

Run time analysis transaction SE30

SQL Trace transaction ST05

Extended Program Check (SLIN)

Code Inspector ( SCI)

<b>Run time analysis transaction SE30</b> :This transaction gives all the analysis of an ABAP program with respect to the database and the non-database processing.

<b>SQL Trace transaction ST05</b>: The trace list has many lines that are not related to the SELECT statement in the ABAP program. This is because the execution of any ABAP program requires additional administrative SQL calls. To restrict the list output, use the filter introducing the trace list.

The trace list contains different SQL statements simultaneously related to the one SELECT statement in the ABAP program. This is because the R/3 Database Interface - a sophisticated component of the R/3 Application Server - maps every Open SQL statement to one or a series of physical database calls and brings it to execution. This mapping, crucial to R/3s performance, depends on the particular call and database system. For example, the SELECT-ENDSELECT loop on a particular database table of the ABAP program would be mapped to a sequence PREPARE-OPEN-FETCH of physical calls in an Oracle environment.

The WHERE clause in the trace list's SQL statement is different from the WHERE clause in the ABAP statement. This is because in an R/3 system, a client is a self-contained unit with separate master records and its own set of table data (in commercial, organizational, and technical terms). With ABAP, every Open SQL statement automatically executes within the correct client environment. For this reason, a condition with the actual client code is added to every WHERE clause if a client field is a component of the searched table.

To see a statement's execution plan, just position the cursor on the PREPARE statement and choose Explain SQL. A detailed explanation of the execution plan depends on the database system in use.

<b>Extended Program Check</b>

This can be called in through transaction SE38 or through transaction SLIN. This indicates possible problems that may cause performance problems.

<b>Code Inspector (SCI)</b>

You can call the Code Inspector from the ABAP Editor (SE38), the Function Builder (SE37), the Class Builder (SE24), or as a separate transaction (SCI).

The Code Inspector indicates possible problems. However, note that, especially with performance issues: There is no rule without exception. If a program passes an inspection, it does not necessarily mean that this program will have no performance problems.

<b>Run time analysis transaction SE30</b>

<b>steps</b>

In Transaction SE30, fill in the transaction name or the program name which needs to be analyzed for performance tuning.

For our case, let this be “ZABAP_PERF_TUNING”

Run time analysis transaction SE30

After giving the required inputs to the program, execute it. After the final output list has been displayed, PRESS the “BACK” button.

On the original SE30 screen, now click on “ANALYZE” button.

The percentage across each of the areas ABAP/ Database/System shows the percentage of total time used for those areas and load on these areas while running the program . The lesser the database load faster the program runs.

<b>SQL Trace – ST05</b>

<b>steps</b>

<u>Starting the Trace:</u>

To analyze a trace file, do the following:

...

Choose the menu path Test &#61614; Performance Trace in the ABAP Workbench or go to Transaction ST05. The initial screen of the test tool appears. In the lower part of the screen, the status of the Performance Trace is displayed. This provides you with information as to whether any of the Performance Traces are switched on and the users for which they are enabled. It also tells you which user has switched the trace on.

Using the selection buttons provided, set which trace functions you wish to have switched on (SWL trace, enqueue trace, RFC trace, table buffer trace).

If you want to switch on the trace under your user name, choose Trace on. If you want to pass on values for one or several filter criteria, choose Trace with Filter. Typical filter criteria are: the name of the user, transaction name, process name, and program name.

Now run the program to be analyzed.

Stopping the Trace:

To deactivate the trace:

...

Choose Test &#61614;Performance Trace in the ABAP Workbench. The initial screen of the test tool appears. It contains a status line displaying the traces that are active, the users for whom they are active, and the user who activated them.

Select the trace functions that you want to switch off.

Choose Deactivate Trace. If you started the trace yourself, you can now switch it off immediately. If the performance trace was started by a different user, a confirmation prompt appears before deactivation-

<u>Analyzing a Sample trace data:</u>

PREPARE: Prepares the OPEN statement for use and determines the access method.

OPEN: Opens the cursor and specifies the selection result by filling the selection fields with concrete values.

FETCH: Moves the cursor through the dataset created by the OPEN operation. The array size displayed beside the fetch data means that the system can transfer a maximum package size of 392 records at one time into the buffered area.

<b>Reward if useful</b>

[Former Member]

I have started writing blogs, partly based on the questions in the forum,

start with

SE30

/people/siegfried.boes/blog/2007/11/13/the-abap-runtime-trace-se30--quick-and-easy

it has also a section on the percentages which the SE30 shows.

If you have 90% database, then you should check the

SQL trace:

/people/siegfried.boes/blog/2007/09/05/the-sql-trace-st05-150-quick-and-easy

This will lead you to the most expensive database statements, there you

check whether the usual recommendations help.

However, usually the problem is a problem with wrong or missing indexes.

Siegfried