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.
-> 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.
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.
It's correct to sort the hit list by net time descending and look at the top few items for tuning possibilities.
However the formula you have given for net time is wrong. Net time is rather the time spent on this particular modularization level only, whereas gross time additionally contains all the time spent on the lower levels. Your example hit list line 4 (subroutine F_SEND_FILES) obviously contains the two WAIT commands, thus the very high gross time compared to the miniscule net time.
Were you successful in finding out why WAIT UP TO 100 SECONDS took so much time? 😉
Yes Thomas; I understood the difference between the gross time and the net time! Thanks for sharing!
No I did not find the answer to your 2nd questions...any technical tips?
Well, I was just pulling your leg there, never mind 🙂
Thanks Tanmoy for your nice blog which is useful very frequently. Keep posting....
Sigh... At the risk of being called mean (yet again) I must point out that there was an excellent blog on SAT already posted back in 2011 by Olga Dolinskaja. Please search before posting.
Yes I know it is a video with a lot of information....but here I have demonstrated a particular case that I faced during production support...
Another one i like is ST12, in which you can club the functionality of erstwhile SE30 & ST05. 🙂
But if i remember correctly TZ had mentioned that it is not officially released for use by customers. But i don't complain, i kind of like it!
Imho SAT gives too much information & i feel lost amidst the data 😕
I think the history of ST12 is that it used to be only available as add-on for SAP support purposes, but it is included in the standard installations since a few releases.
I also use it most of the times, since it so nicely combines SQL and ABAP trace features.
The "one screen fits all" approach looks quite daunting at first though.
I have to admit i started using ST12 after hearing about it from you. 🙂
I think almost all SAPGUI screens look daunting (read: gross 😈 ), don't they? But i think once you get the feel of it ST12 is quite easy to use.
Hello Tanmoy Mondal,
Thank you very much for the blog.
Even I am facing the same problem with OLE_FLUSH_CALL function module.
Could you please help me in knowing solution for this problem?
Thanking you in advance.
If the report runs for 4-6 hours, then these transactions will not be useful for getting the traces. My understanding is that se30/Sat/st05 can get traces for maximum upto 1 hour.Should we go for SQLM in that case? Can anyone pls clarify