Show TOC

Procedure documentationAnalyzing Performance with the ABAP Runtime Analysis Locate this document in the navigation structure

Procedure

You can use the ABAP Runtime Analysis to quantify the performance of your ABAP applications.

You can also use the Runtime Analysis to analyze performance problems by finding out where runtime and memory are being consumed and by identifying bottlenecks in your code.

This section shows you how to do a performance analysis.

Doing a Performance Analysis with the Runtime Analysis

A performance analysis usually starts with an observation that some particular feature of a program is not running as fast as you think it should.

Important: If everything in your system is slow, then analyzing a program with the Runtime Analysis is not likely to help you very much. You need to use transactions such as these:

  • RZ20, the CCMS Alert Monitor

  • ST03, the Workload Monitor

  • ST04, the Database Monitor

  • ST05, the Performance Analysis

  • ST06, the Operating System Monitor

to diagnose a system-wide problem with your NetWeaver installation.

But assume that in your monitoring you have noticed that the average response time of a transaction is too long. Or your users have complained to you about a slow-running program or transaction. Or you have just noticed directly in the system that some program feature is slow to respond.

Here is how to investigate such a performance problem with a particular program or transaction.

  1. Start the ABAP Runtime Analysis by entering transaction SAT or choosing   System   Utilities   Runtime Analysis   Execute.  

  2. Specify a variant that has Aggregation set to Per Call Position.

    The resulting 'ABAP trace' measurement aggregates trace events that occur at the same level in the call hierarchy. For example, ten calls to a function module within a loop results in a single trace record. The record shows 10 hits to function module X with accumulated runtime Y.

    Start with an aggregated trace when you analyze a performance problem. You do not need all the details of program execution; all you need is to see which statements, which procedures, were expensive in runtime.

    Optionally, you can turn the trace on and off on your own. Use this setting in the variant if you know the part of an interactively started program or transaction that you want to trace. You can then limit the trace to the relevant part of a program or transaction.

  3. Start the trace using any of the start methods.

  4. Display the trace from the Evaluate tab in transaction SAT, if it is not displayed automatically.

    You find yourself on the tab Desktop 1. This desktop is set up by default with the Profile and Hit List tools, which are ideal for analyzing performance problems.

  5. Use the Hit List tool to look for conspicuous consumers of runtime.

    The Hit List is sorted by default by net runtime. This is the aggregated time spent doing a particular operation. Net runtime does not include time spent calling other traced operations.

    Questions you can ask yourself as you look at the hit list include these:

    • Are there hit list entries that stand out as consumers of net runtime? If there are, then these are where your program is using its runtime.

      Double-click an entry to see what the underlying code looks like.

    • Do conspicuous entries have many hits? The number of hits characterizes the operation. The Runtime Analysis aggregates trace events only if they occur at the same level in the call hierarchy.

      A large number of hits therefore means that the program repeats processing many times. Perhaps it is processing records from a table or other data source. Check whether the strategy or implementation of the mass processing can be optimized.

      A small number of hits means that you have problems with discrete operations like database accesses or remote calls. A technical solution, such as adding an index to a table may be necessary. Or you may need to shift your analysis to system or network issues, if long latency in remote calls is the problem.

  6. Use the Profile tool to evaluate your performance data from different perspectives.

    The Profile tool lets you sort the performance data in a measurement along different dimensions. Looking at the data from different perspectives can help you categorize and locate performance problems.

    Change the perspective by choosing Other Hierarchy (Other Hierarchy) from the tool bar of the Profile tool.

    Two useful techniques as you analyze the entries are these:

    • Combine perspectives. Mark an entry. From the context menu of the entry, open the entry in another perspective.

      Example: Mark a program entry. Then select Expand Trace Results from the context menu. The Runtime Analysis shows the distribution of the trace events that were recorded for the program.

      Example: From the Package view, use Expand Programs from the context menu to see the distribution of trace events across programs in the package.

    • View trace entries in the Hit List or Times tools. Mark an entry. In the context menu of the entry, choose Display Subarea in Hit List Tool or Display Subarea in Times Tool.

      The Runtime Analysis displays only the trace entries that pertain to the Profile entry.

      Example: You can filter the Hit List or Times tool to show only the activity in a particular program.

    Here are the most useful views, together with some questions that you can ask yourself as you look at the data from each perspective.

    • The Trace Results view sorts trace events according to the selections you made in the Variant on the Statements tab.

      Do particular categories of trace events stand out as consumers of runtime? If so, open the subhierarchies. Do particular subcategories stand out as runtime consumers?

      Some typical suspects: Much time spent in External Processing Blocks suggests that RFC calls, GUI round trips, HTTP calls, and the like are slowing down your program.

      Time spent in Data Accesses External suggests that database operations are taking too long.

    • The Packages view sorts trace events among development packages. You can see which packages appear in the measurement.

      Are your own development packages conspicuous users of runtime? Then you need to look for a performance problem close to home.

      Which programs in stand-out development packages are using much run time? Choose the context menu and Expand Programs.

      What kinds of trace events in these programs are using much runtime? Choose the context menu and Expand Trace Results.

    • The SLAD Object Sets view lets you filter results according to an object set that you have defined in layer-aware debugging (transaction SLAD).

      Apply an SLAD object set to focus only on particular sets of objects — for example, your own code.

In practice, performance problems are often diffuse and multifactorial and therefore correspondingly difficult to analyze.

Without the data and analysis tools offered by the Runtime Analysis, however, analyzing performance problems would be much more difficult or even impossible. The Runtime Analysis quantifies performance and gives you useful tools for working with this data. It is the essential starting point for any performance analysis.

Try It Out: Analyzing an Observed Performance Problem

In the Object Navigator (transaction SE80) of the ABAP Workbench, some people have observed that expanding the BASIS development package takes longer than expected. It may take up to two seconds for the second level of the BASIS hierarchy to open.

This slight performance problem offers a good example for performance analysis in practice.

To analyze the suboptimal performance, apply the procedure above to the following function.

  1. Start transaction SE80 using the In Dialog start method of transaction SAT.

    Use a variant in which you have set the option Explicit Switching On and Off of Measurement.

  2. Set the selection fields in the left-hand side to Package and BASIS.

  3. Turn the trace on, measure the operation Expand All Nodes (button in the selection tool bar), and turn the trace off again.

  4. Display the trace.

Tips for doing the analysis:

  • The Package view in the Profile tool is a good place to start this analysis.

    If you are working over a WAN connection with a high latency, then you may see package SOLE as the highest runtime user under Package BASIS. You can ignore this package: It simply reflects the high latency times in the communication between SAPGUI client and backend system.

    The package of interest for the analysis is called SEU.

  • Try finding out how the SEU runtime is distributed among the programs in SEU and then how trace results are distributed among these programs. You may find that a LOOP AT operation is conspicuous in one particular program.

  • A likely contributor to the suboptimal performance is a 'loop in loop' construction in the source code of the function. See if you can find this construction using the performance analysis.