Performance analysis of long running programs in ABAP

Performance analysis of long running programs in ABAP:

The objective of this blog is to show how to analyze long running programs in ABAP. Customers often complain about some custom reports in ABAP are taking a hell lot of time during the production execution and as a consequence they frequently request to look into the performance killers and the bottlenecks.

Recently, we had a severe performance issue with one such reports in ABAP – a custom report for purchasing contracts. Customer anticipated that the report is running very slow and hence it could not be moved to the production environment. Our team of developers had the job to optimize it. They used the R/3 transaction SAT to understand the bottlenecks and the performance killers.

Starting with SAT:

We have the following report that runs for a long time. The screen-shot of the report is given below

Now we will analyze the performance of this report using the transaction code SAT. Let us run this R/3 transaction, the initial screen of SAT is displayed. Here we are creating a new variant called PERFO_VAR that will contain all the restrictions for the performance measurement.

The variant will have the following characteristics to measure the performance –

1.     Choose Per Call Position radio-button – This implies that it enables call per aggregation. This option is generally used for performance trace.

  The Statements tab will look like the screen-shot below:

After the creation of the variant; we will start the measurement of the transaction. Please see the screen-shot.

Once the measurement is finished; we will go to the evaluate tab to see the results & analyze. W.r.t performance analysis it is best to use the tools – Hit List & Profile to analyze the performance killers.

If we look closely at the Hit List ALV, we can see which entries took most of the time. The entry 1 consumed 79.65% of the net time. The entry 2 consumed 15.93% of the net time.  The entry 3 consumed 4.21% of the net time. Hence the first 3 entries sum up to 99.79% of the net time. We will have a detailed look at these 3 entries to understand why they took so much time. One important thing to note at this point in time is that we are mostly interested in the net time; the net time is the time spent on the specific modularization unit; whereas gross time is the total time spent on the lower level modularization units.

Example:

Perform f_send_files

   -> the net time = 0.05%; time spent spent to call the subroutine (considering this specific modularization unit only).

   -> the Gross time = 95.64;   time spent to call all the related lower level modularization units.

Thanks to Thomas Zloch for correcting…:)

Detailed Analysis with SAT:

Now in the Hit List, when we double click on the 1st entry; we navigate to the code & oops this what we see –

Now in the Hit List, when we double click on the 2nd entry; we navigate to the code & oops this what we see –

Now in the Hit List, when we double click on the 3rd entry; we navigate to the code & oops this what we see –

Therefore it is clear that WAIT/SLEEP & WAIT for RFC takes the most of the time in report. They are the major performance killers.

Conclusion:

SAT is a very useful transaction to do the following things –

1.       Performance Analysis.

2.       ABAP Trace Analysis

3.       Trace Parallel process

4.       User Trace.

It is an extension of commonly used SE30. It is more sophisticated tool & very useful for analyzing production performance issues quickly & neatly.