Runtime Analysis - Analyzing a Complex Program

You should now use a more complex program

SAPBC490_TOOL_CASE_STUDY and inspect it using runtime

analysis. Identify the main reasons for the good or bad performance of this program.

1. Measure this program using SE30.

We recommend starting with a rough analysis using the default variant followed by a detailed analysis with your own variants.

In which program part is the most runtime caused and where do you think is the most potential for optimization? What are the most expensive table accesses, internal table accesses, subroutines, etc.? (expensive= longest runtime and largest number of executions)

How could you then monitor the database accesses in more detail?

Solution 3: Runtime Analysis

Task 1: Runtime Analysis - Analyzing a Simple Program

A specified program is to be inspected using runtime analysis.

Program SAPBC490_TOOL_RUNTIMEANALYSIS is specified. Measure this program using SE30.

Keep in mind that this first exercise for SE30 is intended as an introduction to this tool and you should learn how to use and handle this tool. The object-oriented program to be analyzed therefore does not have too complex a structure or any really performance-critical parts. You will be confronted with a more complex case in the next exercise.

1. First of all, perform a rough analysis of the program. In the first check run, use the DEFAULT variant and observe the resulting hit list in the result. (So you are simply not making any changes to the variant selection.)

a) The program to be checked must be active! In SE30, enter this program in the Program field and start the analysis. You do not have to select anything for Measurement Restriction for the time being.

2. In the second measurement run, use your own variant BC490_##_VAR1. Do not use an aggregation here.

In this run, focus your analysis on subroutines, function modules, OO calls, internal tables and Open SQL calls.

In the result you will see not only the normal hit list but also the group hit list and various analysis functions for object-oriented programming.

Determine the most expensive calls in the individual group categories. (See group hit list)

Continued on next page

Which methods of which classes were called up and which method calls required the most time?

a) Under Measurement Restriction, create a new variant using the Create button. You will then find three tab pages, which you should ideally process from right to left. The aggregation level is defined on the far right. Only the NONE selection returns all results functions later on. If you wanted to analyze the group hit list, for example, you would have to set this to NONE. Use the tab page in the middle to select all program parts that are supposed to be measured and should subsequently be available in the log. You decide, for example, if extra methods are supposed to be traced and measured by pressing the corresponding button.

On the results screen, navigate to the group hit list (second button at the top left) and into the other result functions. The selection buttons in the middle describe the measured method calls, instantiations and so on.

Note: In the analysis of the internal tables, runtime analysis uses technical, symbolic names (IT_XX) for the actual internal tables in the program. If you want to know which itabs are behind the symbolic designations, you have to use the Display Source Code button (icon). This takes you directly to the source code of the program line with the internal table that you are looking for.

Task 2: Runtime Analysis - Analyzing a Complex Program

You should now use a more complex program

SAPBC490_TOOL_CASE_STUDY and inspect it using runtime

analysis. Identify the main reasons for the good or bad performance of this program.

1. Measure this program using SE30.

We recommend starting with a rough analysis using the default variant followed by a detailed analysis with your own variants.

In which program part is the most runtime caused and where do you think is the most potential for optimization? What are the most expensive table accesses, internal table accesses, subroutines, etc.? (expensive= longest runtime and largest number of executions)

Continued on next page

How could you then monitor the database accesses in more detail?

a) Even the first rough analysis with the evaluation of the hit list returns the main cause of bad performance, namely subroutine GET_ELIGIBLE_SALES_ITEMS

In the group hit list, KNA1 and MARC stick out as the most expensive tables.

When you look at the coding of the routine you will notice that nested selects are used. This put a lot of strain on the system. It causes a large number of fetches on the database, the data packages are not utilized well. To analyze these SQL statements in the expensive subroutine in more detail, you could undertake further analysis with the SQL trace.

Exercise 4: Code Inspector

Exercise Objectives

After completing this exercise, you will be able to:

• Identify program parts critical to performance with the Code Inspector tool.

Business Example

A company operates customer developments and would like to check their own programs for performance-critical areas.