This presentation shows how performance optimization was conducted on a certain ABAP source code that ran very, very slow (several hours to even days or weeks). It shows how the problem was detected and provides recommendations on how to tweak the code for faster performance. The following is an unformatted, plain-text transcription of the presentation:
Performance Analysis on an ABAP code that runs extremely slow.
Outline
• The First Problem
– The First Recommendation
• The Second Problem
– The Second Recommendation
The First Problem
• Analyzing the hit list of the THE_SLOW_SOURCE_CODE reveals that the “Fetch MARC” statement consumes about 70-80% of total run time.
The First Problem
The First Problem
• The “Fetch MARC” statement:
The First Problem
• So what’s so special with the “Fetch MARC” statement?
• Assuming THE_SLOW_SOURCE_CODE runs for 10 hours in Server6P, this single statement consumes around 7-8 hours.
• It accesses 3 massive tables that are growing really fast in Server6P. Next slide shows a comparison of the number of entries in Server6A and Server6P which is about 6-12 months difference since last synchronization (refresh).
The First Problem
The First Problem
• Analyzing the trace list of the “Fetch MARC” statement reveals the following:
The First Problem
The First Problem
The First Problem
• Analyzing the T_WERKS table...
The First Problem
The First Problem
• Based on the trace list, we see that the “for all entries” addition is split into chunks of 5, so that the 500 entries in T_WERKS are split into 100 native SQL statements containing 5 plant codes each.
The First Problem
The First Recommendation
• Remove the “for all entries” addition in “Fetch MARC” statement. Then use a “delete table” statement to filter out unwanted plant codes.
• Add range R_WERKS to hold T_WERKS data
• Add WERKS field in T_MDBS internal table
• DELETE TABLE t_mdbs WHERE werks NOT IN r_werks.
The First Recommendation
• We experiment with the original “Fetch MARC” statement against the first recommendation:
– Source code of first problem (abench)
– Source code of first recommendation (ctrial)
The First Recommendation
• Testing reveals a 90% drop in response time in Server6A.
The First Recommendation
• Non-negative impact testing also passed, as long as we sort T_MDBS by the same fields in the first problem and in the first recommendation, and delete duplicate adjacent entries.
The First Recommendation
• Trace list reveals a marked improvement of a 1:1 correspondence between Open SQL and native SQL statements, compared to the 1:100 ratio in the original “Fetch MARC” statement.
The First Recommendation
The First Recommendation
• Assuming, “Fetch MARC” statement consumes 70-80% of THE_SLOW_SOURCE_CODE total run time, then a 90% decrease in the statement through this first recommendation should ideally translate to a 63-72% decrease in THE_SLOW_SOURCE_CODE total run time.
The First Recommendation
• Testing the first recommendation on the actual tool in Server6A shows a decline of about 30%.
The Second Problem
• When the THE_SLOW_SOURCE_CODE tool is modified with the first recommendation, running a run time analysis yields the following hit list:
The Second Problem
The Second Problem
• “Fetch MARC” statement is now reduced to 10% of run time compared to the previous 75%.
• “Fetch EKKO” statement consumes 70% of run time.
• “Fetch EKKO” statement comes from 2 sources:
– Form F2000_103_105 (Fetch_EKKO_F2000)
– Form F4000_ISTO_RISTO (Fetch_EKKO_F4000)
The Second Problem
• Comparing Fetch_EKKO_F2000 and Fetch_EKKO_F4000 reveals several similarities in the statements.
The Second Problem
The Second Recommendation
• Merge Fetch_EKKO_F2000 and Fetch_EKKO_F4000 into a single statement: Fetch_EKKO_F1500.
• In forms F2000_103_105 and F4000_ISTO_RISTO, filter out unwanted records.
• In this way, fetching from EKKO is done only once instead of twice.
The Second Recommendation
The Second Recommendation
The Second Recommendation
• We experiment with the original “Fetch EKKO” statement and the second recommendation:
– Original (cbench)
– The second recommendation (ftrial)
The Second Recommendation
• Testing reveals 16-31% drop in run time in the “Fetch EKKO” statement.
The Second Recommendation
• Non-negative impact testing also passed, as long as:
– T_PO table is sorted with the same fields in both the original and in the second recommendation
– Adjacent duplicate entries in T_PO are deleted in both original and in the second recommendation using the same fields used for sorting
