Analysis Tools - Runtime Analysis

Runtime Analysis

http://help.sap.com/saphelp_nw73ehp1/helpdata/en/4a/2f5264cfc4044fe10000000a421937/content.htm

Created on April 04, 2014

The documentation may have changed since you downloaded the PDF. You can always find the latest information on SAP Help Portal.

Note

This PDF document contains the selected topic and its subtopics (max. 150) in the selected structure. Subtopics from other structures are not included.

© 2014 SAP AG or an SAP affiliate company. All rights reserved. No part of this publication may be reproduced or transmitted in any form or for any purpose without the express permission of SAP AG. The information contained herein may be changed without prior notice. Some software products marketed by SAP AG and its distributors contain proprietary software components of other software vendors. National product specifications may vary. These materials are provided by SAP AG and its affiliated companies ("SAP Group") for informational purposes only, without representation or warranty of any kind, and SAP Group shall not be liable for errors or omissions with respect to the materials. The only warranties for SAP Group products and services are those that are set forth in the express warranty statements accompanying such products and services, if any. Nothing herein should be construed as constituting an additional warranty. SAP and other SAP products and services mentioned herein as well as their respective logos are trademarks or registered trademarks of SAP AG in Germany and other countries. Please see www.sap.com/corporate-en/legal/copyright/index.epx#trademark for additional trademark information and notices.

Table of content

Table of content

1 Runtime Analysis

1.1 ABAP Runtime Analysis: Release Notes()

1.2 ABAP Runtime Analysis: Useful Techniques

1.2.1 Analyzing Performance with the ABAP Runtime Analysis

1.2.2 Finding Performance Hotspots with the ABAP Runtime Analysis

1.2.3 Analyzing a Long-Running Process with the ABAP Runtime Analysis

1.2.4 Tracing HTTP Requests and Other Requests with the ABAP Runtime Analysis

1.2.5 Finding Messages and Other Statements with the ABAP Runtime Analysis

1.3 Creating Measurements

1.3.1 Setting the Measurement Accuracy

1.3.2 Variant Definitions

1.3.3 Executing Measurements

1.3.3.1 Executing a Trace in Dialog

1.3.3.2 Executing a Trace of a Parallel Work Process

1.3.3.3 Executing a Measurement in the New ABAP Debugger

1.3.3.4 Scheduling a Measurement: The ABAP User Trace

1.4 Performance Results

1.4.1 Adapting Message Display

1.4.2 Measurement Display Tool

1.4.2.1 Hit Lists

1.4.2.2 Database Tables

1.4.2.3 Profiles

1.4.2.4 Processing Blocks

1.4.2.5 Call Hierarchy

1.4.2.6 Times

1.4.3 Comparison Tools

1.4.3.1 Hit List Comparison

1.4.3.1.1 Hit List Comparison Results

1.4.3.1.1.1 Individual Lines

1.4.3.1.1.2 Event Hierarchy

1.4.3.1.1.3 Program Hit Lists

1.4.3.2 Call Hierarchy Comparison Results

1.4.3.2.1 Hierarchy Comparison

1.4.4 Display Filter

1.5 Tips and Tricks

1.6 Measurable Components

1 Runtime Analysis

Use

The runtime analysis allows you to examine the performance of ABAP programs such as reports, subroutines, function modules, or classes.

You use the results of the runtime analysis to identify runtime-intensive statements and to show the hierarchy of program calls. From the results, you can identify: Excessive or unnecessary use of modularization units

CPU-intensive program functions

Note

You can also use the Runtime Analysis tool to analyze ICF services. In particular, you can evaluate Web Dynpro ABAP applications and BSP applications.

Integration

The runtime analysis is an integrated test tool within the ABAP Workbench.

They can call them from any screen. Choose System Utilities Runtime Analysis Execute for this.

Features

The runtime analysis measures the CPU time required by ABAP statements. For more information, see Measurable Components.

The tool stores the measurement results in tables on the database, rather than on the current server. This way, the results are visible in the whole system. The traces are saved in a non-release-specific plain text format.

To display the results, the runtime analysis uses the standard SAP list, which is accessible and allows sorting, summation, and other functions.

1.1 ABAP Runtime Analysis: Release Notes()

Technical Data

Use

NetWeaver Release 7.0 EHP2

1. Replacement of the old ABAP Runtime Analysis transaction SE30 with the new transaction SAP, as part of a major revision and extension of the ABAP Runtime Analysis.

2. Replacement of the old display infrastructure of the ABAP Runtime Analysis with the tools framework used by the new ABAP Debugger. 3. Re-design of the user interface. The new main screen offers tabs for performing measurements and displaying measurement results.

4. Replacement of the old SE30 list-based measurement displays with new tools using accessible ALV technology. The new tools offer in many cases advanced features not available in the old SE30 call hierarchy, hit list, and database hit list tools.

5. Addition of entirely new tools for analyzing measurements:

The Profile tool, for sorting trace events along various dimensions. Example: packages involved in the processing during a measurement. The Processing Blocks tool, for displaying an easily usable view of the call stack during a measurement.

The Times tool, for analyzing the runtime spent in measured events.

6. Storage of measurements in the database rather than in operating system files. This change allows you to display measurements from all of the application servers in a system, not just the server on which the measurement was made.

7. Export of measurements in a release-neutral and operating-system-neutral format. This feature allows you to compare measurements across releases and host operating systems as of NetWeaver Release 7.0 EHP2.

8. The capability of ending measurements stuck in status Running (from the Evaluate tab of the start screen). NetWeaver Release 7.0 EHP3

1. In the Overview of Scheduled Measurements , you can now schedule measurements not only for the local application server, but also for selected other servers or all servers.

You can also now display scheduled measurements system-wide.

2. In the Overview of Scheduled Measurements , you can now schedule measurements in clients other than your own. You must still logon in the client in which a measurement was made to display the measurement.

3. In measurement of parallel processes, you can now start and stop measurements in work processes of other application servers in the system. Further, by default, the display starts with only active work processes, to make it easier to find a running process that is to be traced.

4. Usability improvements:

In measurement of external processes, you can activate or de-activate a measurement simply by clicking on a work process entry. It is no longer necessary to mark an entry and then choose a function in the toolbar.

The messages that document the progress and success of a measurement have been reworked to be more informative.

You can change the description of a measurement without causing, as was the case in the past, the entire trace to be stored once again.

You can display the raw measurement data directly from the Evaluate tab. In earlier releases, you had to enter the OK-Code DUMP in the Command field to display the raw data.

A user-filter setting in the Evaluate subscreen - to view measurements of other users - remains in effect as long as you remain logged on. The Runtime Analysis issues a warning message if you open the Evaluate subscreen while such a user-filter setting is in effect.

1.2 ABAP Runtime Analysis: Useful Techniques

As of NetWeaver Release 7.0 EHP2

1.2 ABAP Runtime Analysis: Useful Techniques

Procedure

The ABAP Runtime Analysis is a powerful tool for doing the following: Analyzing the performance of a program

Analyzing the program flow (execution path) of a program.

The following topics show how to use the Runtime Analysis for various types of performance and program flow analyses. Performance Analyses

1. Analyzing Performance with the ABAP Runtime Analysis 2. Finding Performance Hotspots with the ABAP Runtime Analysis Program Flow / Program Execution Analyses

1. Finding Messages and Other Statements with the ABAP Runtime Analysis 2. Analyzing a Long-Running Process with the ABAP Runtime Analysis 3. Tracing HTTP Requests and Other Requests

1.2.1 Analyzing Performance with the ABAP Runtime Analysis

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 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.

1.2.2 Finding Performance Hotspots with the ABAP Runtime

Analysis

Procedure

You can use the ABAP Runtime Analysis to scan your code for hotspots in runtime or memory use. You can use the hotspot analysis to zero in quickly on procedures that may need optimization or refactoring.

This section shows how to use the hotspot scanning function of the Runtime Analysis. Finding Runtime and Memory Hotspots in Measurements

Here is the procedure for scanning code for runtime or memory hotspots.

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 None.

The resulting 'ABAP trace' measurement records trace events individually, so that you can search for particular ABAP statements. If you want to scan for memory hotspots, then set the option Measure Memory Use in the variant.

Optionally, you can turn the trace on and off on your own. Do this 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 non-aggregated measurement (ABAP trace) using any of the three Runtime Analysis start methods. 4. Display the trace when it is done, if it is not displayed automatically.

You find yourself on the tab Desktop 1 , which is set up by default for analyzing performance.

Switch to the tab Desktop 2 , where you find tools for analyzing program flow, the Call Hierarchy and the Processing Blocks tool. 5. Scan the measurement for runtime or performance hotspots. Switch to the Processing Blocks tool. Then click .

The Runtime Analysis opens a dialog box for customizing the hotspot scan. 6. Decide which of the three scans you would like to use.

Here is how you can use each scan:

Percentage of Total Runtime (Gross) : Find out where your program spent most of its clock runtime.

The scan marks the processing blocks (method, function module, form routine calls and the like) with start to finish elapsed times (gross runtimes) that are over the limit you specify.

Percentage of Total Runtime (Net) : Find the processing blocks in which your program used runtime most intensively.

The scan marks processing blocks which were large net users of runtime, not counting any other processing blocks that were called within them.

Start with a high specification in the LimitVal field, such as 20%. That way, you can see quickly whether there are highly intensive net users of runtime.

Note

Gross Runtime is simply the elapsed time between the start and end of a processing block. Net Runtime is usually more useful, because it does not count runtime spent in other processing blocks. Net Runtime is only the time spent processing code directly in a processing block. Memory Increase in Processing Block : Find the processing blocks that are conspicuous consumers of memory. The Runtime Analysis measures memory in use at the start and end of each processing block. It can therefore calculate how memory use changed during the execution of a processing block.

The scan marks processing blocks which may contribute to any memory-related problems you are analyzing.

The Processing Blocks tool marks any processing blocks found by the scan in red. It also opens the call stack to each such processing block. 7. Once you have found memory or runtime hotspots, use the other tools of the Runtime Analysis to analyze them.

Here are some ways to find out why a particular processing block is a large user of net run time or of memory:

Tell the Runtime Analysis to display only trace records relating to a hotspot. To do this, put the cursor on the hotspot in the Processing Blocks tool. Then choose from the tool bar of the Processing Blocks tool.

The Runtime Analysis tools now display only trace records that pertain to the hotspot.

You can now work with this set of trace records as though it were the entire measurement. You can for example look for hotspots again within the hotspot processing block. You can also examine the processing in the hotspot in detail in the Call Hierarchy or Times tools. You don't have to worry about where the records of the hot spot begin or end in these detailed displays.

Switch to the Call Hierarchy or Times tools to see the detailed trace of processing in the hotspot. Mark the hotspot, and choose the function that you want to use from the context menu.

Note that the net run time that you see will differ between the Processing Blocks tool and the other tools. This is because the Call Hierarchy and Times tool present much more detailed measurement data. The net runtime of the hotspot is therefore divided up among the subsidiary trace records of the hotspot.

Jump into the source code from detailed records in the Call Hierarchy or Times tools. You can analyze the source code to understand why individual operations in the measurement are expensive in runtime or memory consumption.

You can also leave breakpoints or set up watchpoints if you want to reproduce the problem in the debugger. Try It Out: Look for Hotspots in the Object Navigator (Transaction SE80)

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:

Look for hotspots that consume 20% or more of the net runtime of the measured operation.

Take a look at the code in the hotspot that you find. The high resource usage most likely comes from the loop in loop construction in the code.

1.2.3 Analyzing a Long-Running Process with the ABAP Runtime

Analysis

Procedure

You can use the ABAP Runtime Analysis to trace program execution in other work processes in your system.

For example, you can trace the execution of a long-running background job. The trace lets you see what the job is doing - whether it is looping or is doing the work it should be doing.

Tracing a 'parallel session', as the function is called on the transaction SAT measurement screen, is faster and safer than trying to capture a long-runner in the debugger:

Faster, because although you can capture a running process in the debugger from transaction SM50, the Process Overview , you cannot control where the program stops in the debugger. The chances are that you will land somewhere in infrastructure code. It can take a long time for you to orient yourself and understand what the program is doing.

Safer, because you run the risk in the debugger of inadvertently affecting the program's execution. The ABAP Runtime Analysis traces a program without interfering with it.

Tracing an External Process

Assume that there is a background job running in your system. The runtime is in excess of what you would expect for the job. Perhaps it is also showing unexpected activity in the Process Overview , transaction SM50, such as reading persistently from a single table.

Here is how to trace the background job without interfering with it. From the trace, you can find out what the job is doing and whether it is doing what it should be doing.

You can use this procedure to trace activity in any type of work process.

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 None.

The resulting 'ABAP trace' measurement records trace events individually, so that you track the program flow and understand what the program is doing. 3. Start the non-aggregated measurement (ABAP trace) using the Switch On/Off button in the In Parallel Session frame on the Measure tab.

The ABAP Runtime Analysis shows you a list-based variant of the SM50 Process Overview . 4. Activate the trace. Click the work process that you wish to trace.

The Runtime Analysis displays a status message to show that the measurement has been activated.

An icon shows that the measurement still has not yet started.

When the icon shows, the trace is running. You can click the process again to deactivate the trace for display.

If the Runtime Analysis shows the message Trace file not yet written. Do you want to wait? , then choose the Cancel button to terminate and display the trace.

Initially, the process-list display shows only active work processes in the local ABAP application server. You can show all work processes in the server by choosing All Processes .

You can trace one or more work processes in other servers or all servers by choosing Server Selection . 5. In the measurement display, switch to the Desktop 2 tab to analyze the measurement.

Desktop 1 , where the display starts, is set up for analyzing performance. You need Desktop 2 , for analyzing program execution.

6. Analyze the call stack to see what the program is doing.

On Desktop 2 , open the Processing Blocks tool to get a clearer view of the program's call stack. If you see repetition in the sequence of processing blocks, then double-click on the entries to look at the code.

You will not be able to examine the value of variables, as you could in the Debugger. But you can probably judge whether the repetition is for doing proper work, like processing a sequence of customer records.

7. Get more detail on program activity by jumping to the Call Hierarchy.

Do you need to see the program flow in more detail? Then use the context menu of Processing Blocks entries to jump over to the Call Hierarchy tool. Choose Position in the Hierarchy Tool .

There, you can see the individual trace entries related to each processing block. You can also filter the Call Hierarchy to show only the trace entries related to individual processing blocks.

The clear call stack trace offered by the Processing Blocks tool and the detailed tracing offered by the Call Hierarchy tool may be enough to let you judge whether the long-running program is doing what it should be doing.

If you feel that you need to examine the variables in the debugger to see what the long-runner is doing, then you can leave breakpoints in the source code so that you can stop in the debugger.

Try It Out: Trace a Long-Running Process Try out the procedure shown above.

Here is how to start a harmless long-runner, which you can easily stop. Then use the procedure above to find out if the program is looping or doing useful work. 1. Start transaction SE38 and use it to start the program BTCLOOP.

2. The SE38 window hangs, of course. But you can click the icon in the upper left corner of the SAPGUI window to open a context menu. Select Create Session from the context menu to open a new SAPGUI window.

3. In the new SAPGUI window, start transaction SAT. Now use the procedure above to trace and analyze the BTCLOOP program running in a DIA work process on your local server.

4. When you are done with your trace, stop the BTCLOOP program. In the hanging SE38 session window, click the icon in the upper left corner of the SAPGUI window. In the context menu, choose Stop Transaction . The SE38 transaction and the BTCLOOP program are terminated.

1.2.4 Tracing HTTP Requests and Other Requests with the ABAP

Runtime Analysis

Procedure

You can use the ABAP Runtime Analysis to trace program executions in your system:

That result from external calls into your system. You can trace, for example, HTTP or Web services requests, web dynpro requests, or RFC function calls that are processed in your system.

When you do not know when or by which user a program or transaction will be started.

You can trace these kinds of activities with the user-trace feature of the ABAP Runtime Analysis. The user trace lets you start a trace automatically when conditions that you specify are met.

Here is the procedure for using the 'user trace' to trace program execution. We use the example of an HTTP request processed in your system. Analyzing an HTTP Request That Is Processed in Your System

Assume that you need to analyze the program flow (or the performance) of an HTTP request that is handled by your system. Here is the procedure for analyzing the program flow of the request.

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 None.

The resulting 'ABAP trace' measurement records trace events individually, so that you can search for particular ABAP statements. Be sure that the option Explicit Switching On and Off of Measurement is not marked on tab Duration and Type in the active variant. 3. Schedule a measurement. Click Schedule in the For User/Service frame on the SAT Measure tab.

The Runtime Analysis shows you the Overview of Scheduled Measurements . 4. Click to specify the start conditions for a measurement.

On the schedule dialog box, make the following specifications:

Leave User blank - the Runtime Analysis traces a call from any user, if it meets your other specifications. Specify the client in which the call will be processed.

Client 000 is used for anonymous HTTP requests. If no logon information is specified in a service definition (for example, in transaction SICF, the ICF Service Manager ), then the logon occurs on the system default client.

You can specify a client other than the one on which you are logged on. But you must specify a client, or the Runtime Analysis will fail to write a trace. Set Server Name to <ALL> to trace the request no matter on which application server of the system it is processed.

The Runtime Analysis schedules a measurement for each application server in your system. When the measurement has been done on one server, you can delete the scheduled measurements that you do not need.

Set Process Typ e to HTTP and Object Type to URL

The Possible Entries help on these fields shows you the wide range of activities that you can measure. Not all of the possible combinations are sensible. For example, Process Type RFC and Object Type URL will never produce a trace.

In Object Name , type in the URN (path and service name) of the service. You can find the URN of a service in transaction SICF or in the Web Services Manager.

For example, you could enter /sap/bc/ccms/monitoring/grmg_app.

Leave the other fields unchanged.

5. Click on the dialog box to schedule the measurement. The measurement is added to the Overview with Status In Process .

6. Check whether the scheduled measurement has been done. Refresh the Overview of Scheduled Measurements . If the measurement has been made, then:

The Status of the measurement at the application server where the request was processed now shows Executed . The Started column shows the number of traces that have been made.

If Started continues to show the value 0, then no trace has been made. Ensure that you specified the correct client for processing, that the URN is correct, and that you were able to log on to the system successfully.

7. Display the measurement. Leave the Overview of Scheduled Measurements and display the new measurement from the Evaluate tab of the main SAT screen.

If you traced a request in another client, then you must log on to that client to display the trace. 8. Stay on Desktop 1 if you are interested in the performance of the request handler.

The Profile tool shows you the total runtime of the request handler in the top Runtime Measurement line.

The Hit List tool on Desktop 1 shows you the most intensive aggregated users of runtime sorted according to their net runtime.

The Hit List shows you top users from both the HTTP infrastructure, over which you have no control, and your application, over which you do have control. Return to the Profile tool and choose to display the trace events sorted by development package.

Mark the package in which your application resides and choose and then Display Subarea in Hit List Tool to tell the Hit List to display only the entries that pertain to your application's package. Now you can evaluate the performance of your application code, in isolation from entries that pertain to the HTTP infrastructure.

9. Switch to Desktop 2 if you want to analyze the program flow of the request handler.

Start with the Processing Blocks tool. This shows you a clean and clear view of the call stack of the request handler.

Open the processing blocks hierarchy until you find the processing in your own application logic. You can do any of the following to analyze the execution of your code

Choose to search for processing blocks in your application code that consume conspicuous amounts of memory or processing time. You can use this function to scan the code in your request handler that might deserve optimization or refactoring.

Choose to tell the Processing Blocks tool and also the Call Hierarchy - also on Desktop 2 - to display only the trace events that pertain to your code.

In the filtered Call Hierarchy , you can analyze the processing in your application in detail. A double-click on any entry takes you to the corresponding location in the source code.

Double-click these entries to jump to the corresponding locations in source code. You can examine your code in detail and set breakpoints or watchpoints to help you analyze the code in the debugger.

Try It Out: Trace an HTTP Request Try out the procedure shown above.

Schedule a measurement for an HTTP request. Use the URN shown above in the example in Step 4. Then use a browser to send a request of the same type to your system:

1. Prepare test HTTP request. Open a browser. In the Address field, enter a request to one of the servers in your system:

http://<host>:<port>/sap/bc/ccms/monitoring/grmg_app

Example: http://host22:50000/sap/bc/ccms/monitoring/grmg_app

Use transaction SM51, SAP Servers , to get the <host>, host name of a server, from the Host Name field.

Use transaction SMICM, the ICM Manager , on the server you chose to find out the HTTP<port> number. Choose Goto Parameters Display to find the port number (labeled with PROT=HTTP, PORT=<port number>).

GRMG_APP is a service present in most current releases of NetWeaver. It may be called without fear of side-effects in the system. 2. Send the request.

The browser presents a logon dialog box. Log in under your user or another user.

The request ends with an error message in the browser (this is expected: the service expects a special type of request). 3. Display the trace of the request.

1.2.5 Finding Messages and Other Statements with the ABAP

Runtime Analysis

Procedure

If a short dump occurs in a program, you know exactly where in the ABAP code the problem occurred.

But what do you do if an unexpected error message occurs in one of your programs, perhaps because the program has encountered unforeseen conditions? How can you find out where in the code the message was issued? That's the first bit of information you need for analyzing the problem.

The ABAP Runtime Analysis provides a fast and easy way to find out where an error message was issued in the code. You can also use the Runtime Analysis just as easily to find other important statements, such as SQL statements or calls to methods, function modules, or form routines.

Here is the procedure for doing a program flow analysis to do the following: Find a particular statement, such as an error message

Display the call stack that lead to the statement

Finding an Error Message and Displaying the Call Stack with a Program Flow Analysis

Assume that you need to analyze an unexpected error message that has been issued by an ABAP program. Follow this procedure to find the location at which the error message was issued and the call stack that lead to the message.

1. Use the message F1 help to find out the message ID and message number.

The message ID and number are shown at the top of the help. For example the string BT005 in the help window means message ID ' BT' number 005 (in transaction SE91).

Click a message in the status line to start the F1 help. Or choose the Help button on messages in dialog boxes.

The message ID and number let you find the message faster in a runtime analysis measurement. You can also be sure that you have found the right message, if more than one was measured.

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

3. Specify a variant that has Aggregation set to None.

The resulting 'ABAP trace' measurement records trace events individually, so that you can search for particular ABAP statements.

Optionally, you can turn the trace on and off on your own. Do this 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.

4. Start the non-aggregated measurement (ABAP trace) using any of the three Runtime Analysis start methods. 5. Display the trace when it is done, if it is not displayed automatically.

You find yourself on the tab Desktop 1 , which is set up by default for analyzing performance.

Switch to the tab Desktop 2 , where you find tools for analyzing program flow, the Call Hierarchy and the Processing Blocks view. 6. Find the MESSAGE statement in the Call Hierarchy . In the Call Hierarchy tool bar, click .

In the search dialog box, enter the name of the statement or event that you want to find. To find a message, enter MESSAGE. If you know the message number and type, you can make the search more precise: MESSAGE E005, for example.

The trace events in the Call Hierarchy represent ABAP statements schematically, not exactly as they appear in the source code. Browse through a trace to find examples if you are not sure how to search for a particular trace event.

The Call Hierarchy responds by showing the trace entries found by your search in a dialog box.

7. In the dialog box of trace entries that were found, double-click an entry to jump to the exact location of the entry in the source code. In response, the ABAP Runtime Analysis opens the ABAP editor to show the MESSAGE statement or other event for which you have searched. You have found where the message or other event occurred.

In the editor, you can analyze the code. You can set a breakpoint or watchpoint so that you can stop in the debugger when you reproduce the problem. Continue to the next step to see how to display the call stack that lead to this trace event.

8. Leave the ABAP Editor to return to the list of trace entries that were found. 9. Find the location of the MESSAGE entry in the list of trace entries in the Call Hierarchy .

Mark the message entry or other entry that you found. In the tool bar of the search window, choose .

In the main screen of the Call Hierarchy , the Runtime Analysis marks the position of the entry in the list of trace events. Leave the Find dialog box to return to the main screen of the Call Hierarchy .

10. Display the call stack in the Processing Blocks tool.

Open the context menu of the marked entry in the Call Hierarchy display. Select Position in the Processing Blocks Tool .

The Processing Blocks tool is the other tool on the standard Desktop 2 tab. It opens automatically to show the processing block in which the trace event in the Call Hierarchy occurred.

The Processing Blocks tool gives you a clear display of the call stack that lead to your trace event. The processing block (a dialog module, method, function module, or other modularization unit) in which the event occurred is highlighted in green.

You can use the call stack to understand how the program reached the location at which the error occurred. Of course, you can jump into the code from any entry in the Processing Blocks tool to analyze the code or set additional breakpoints.

Try It Out: Finding Statements in Source Code Try out the procedure shown above.

Do the following to generate a harmless error message. Then find the location of the error message using the procedure above. 1. Start transaction ST22, the ABAP Runtime Error viewer.

2. In field User , replace your own user ID with a nonexistent user name, such as XXX. 3. Click Start to search for short dumps of user XXX.

Now use the ABAP Runtime Analysis and the procedure shown above to find out where in the source code the error occurred.

1.3 Creating Measurements

Use

The purpose of this process is to define what to measure and what parts of it to measure. You also use it to define how and when the measurement must take place.

Process

After you start the runtime analysis, the system displays the Measurement tab page by default. You use this tab to define and execute a runtime measurement. The procedure for creating a measurement is as follows:

1. Check the traffic light for the Reliability of the Target Values . Can you execute a reliable runtime analysis in this system? The light is green if there are no reasons why you should doubt the reliability of the runtime determination.

The clock resolution and type of kernel can influence the reliability. A relevant traffic light color and message is displayed if the reliability of the values is affected.

To set the clock resolution, see Setting the Measurement Accuracy.

2. Define the measurement strategy. Select a measurement variant for the measurement. There are both personal and system-wide variants. You can also create a measurement variant of your own by selecting , adapting the measurement settings, and saving the measurement variant. Specify the description of a new measurement variant in the Short Description field. If you do not enter a description, the system automatically assigns the name of the measurement variant as the value for this entry field.

For more information, see Variant Definition.

3. You can choose to have the names of internal tables filled in the runtime measurement.

At runtime, the ABAP runtime system does not know the names of the internal tables. Instead, they are enumerated and appear in the trace with the pseudo-name IT_<Number>.

If you select the With Names of Internal Tables checkbox in the Data Preparation area, the system attempts to parse the real (ABAP source) names of the internal tables at the time of the trace analysis. This is a resource consuming option.

It only makes sense to select this option if you have activated the tracking of operations on internal tables in the measurement variant. Such operations are not tracked by default.

4. Now execute your measurement.

After you have defined the measurement settings, you can create the measurement in one of three execution modes: Create a measurement interactively in dialog mode.

In this mode you execute the program to be measured interactively in that you can execute any functions of the program. In this way you can measure the functions that you think are adversely affecting performance in a targeted way.

Execute a measurement in a parallel mode.

In this mode you can activate the runtime measurement in specific work processes on the local server. In this way you can, for example, include the execution of a long-running program for the runtime analysis.

During activation the internal mode that is currently running is measured or the internal mode that comes next in the work process. An internal mode basically corresponds to a program that is to be executed. If the internal mode is ended or rolled out after a dialog step, then the measurement is also ended.

You can activate the runtime analysis at the same time in up to ten work processes. Plan a measurement execution.

With this mode you can measure programs that you cannot start interactively in the runtime analysis. For example, you can measure the execution of Web Dynpro, BSP, and Web service application using scheduling as well as the executing of programs in the background processing.

For more information, see Executing Measurements.

Result

After you have created and executed a measurement, a trace file with the measurement results is created and stored on the database. You can display and analyze the results of a measurement using the Evaluate tab.

For more information, see Measurement Results.

Note

If you measure the same transaction or program several times, the data can vary. Many factors make it difficult to reproduce identical performance data twice. In the first runtime analysis the system reads data records directly from the database, for example. In a second run, the system reads from the table buffer on the application server.

Performance data also depends on the overall system or network load. For example, the number of active jobs or programs in your SAP system can seriously affect the runtime.

1.3.1 Setting the Measurement Accuracy

Use

1. To set the measurement accuracy, choose Settings Utilities Settings Measurement Accuracy... . You go to a dialog box.

2. You can choose between: High

This accuracy level uses a platform-specific high-resolution clock. This resides in a special part of the host. This option reduces the probability of measurement results being incorrect. However, if you use high-resolution measurement, the maximum measurement interval is shorter. The activating ABAP statement is: SET RUN TIME CLOCK RESOLUTION HIGH.

Low

This option uses a lower resolution. Consequently measurement errors are more likely. However, low resolution has a greater maximum measurement interval. The activating ABAP statement is: SET RUNTIME CLOCK RESOLUTION LOW.

Note

When you record times, remember that the absolute times returned are unreliable in the following circumstances:

For some multiple processor machines if a processor switch occurs. See the syntax documentation for the statement SET RUN TIME CLOCK RESOLUTION in transaction ABAPHELP for this.

On single-processor hosts when the clock rolls over.

Recommendation

We recommend that to obtain a representative runtime measurement, you execute some pre-runs of your application to fill buffers and to avoid program generation in your true measurement.

Clock Interval

The clock interval specifies the time in seconds before the clock rolls over. To display the default clock interval, choose Utilities Measurement Interval .

1.3.2 Variant Definitions

Use

You use this function to define a variant that specifies the measurement to specific criteria.

A measurement variant defines how a program is measured. You can execute a measurement using either personal or default variants delivered by SAP without having to branch to the variant maintenance.

If you want to adapt the measurement results to your needs, then you can either create or adapt measurement variants.

Features

The Variant screen contains the following tabs: Duration/Type

You can set the maximum size of the trace files in kilobytes and the maximum runtime in seconds.

If the file size of the execution time is exceeded during the measurement, then the measurement is canceled. The generated trace file then only contains the measurement values that were determined until the stop time.

The maximum duration period (assuming there is anough space in the file system) is around 4293 seconds. In the Aggregation screen area, you can select one of the following:

None - With the setting No Aggregation the measurement data is recorded in detail. This type of measurement enables a detailed runtime analysis when using all the hit lists and the call hierarchy.

The call hierarchy records all Measurable Components. It can also serve as a trace for these components.

For Each Call Point - For all calls in the same position in the source code a single entry is written to the measurement data file. The entry aggregates the runtimes of all calls.

In Options screen area, you can set the following indicators: Measuring RFC and Update Calls

If you select this checkbox, you trigger runtime measurements for the update initiated by the application you are tracing, or for the remote function calls in an external SAP system that have been invoked by your application.

Activating/Deactivating Measurement Explicitly

If you select this checkbox, you can trace section of your application instead of the whole run. These sections can be initiated or ended, by entering

/ron or /roff in the command field or by choosing System Utilities Runtime Analysis Activate or System Utilities Runtime Analysis Deactivate .

The runtime analysis can also be activated or deactivated at the program side with the statement SET RUN TIME ANALYZER ON or OFF in the source code.

Measure with Memory Use (if aggregation not used)

If you select this checkbox, you can additionally measure the memory consumption in the course of the program execution. Statements

You use this tab to select specific statements to be measured. The runtimes of the statements that you do not select are still measured, but they are not displayed individually in the measurement results and their time is added to the total runtime.

This tab contains the following statement groups: Processing Blocks

dynpro Internal Tables

Read and change operations on internal tables are not selected by default due to memory considerations. Since operations on internal tables often count as performance problem spots, do not hesitate to activate these statement options.

Database Accesses

The DB-Level Operations is a read-only checkbox and is selected by default. This assures that external database times (the time spent on the database server and not on the SAP database interface) are always measured and can be distinguished from the time components spent on the DB interface.

Data Transfer Generate and Load Other

The Kernel-level Runtime Administration checkbox is not selected by default. This switch is for SAP internal use

You can select or deselect all checkboxes at once, by choosing with the quick info text Select All or with the quick info text Deselect All . Program Parts

On this tab you can restrict the measurement to specific objects. The table contains the following columns:

Note

You can also filter measurement results at a later date. For this purpose, read the section Display Filter.

If you select Measure functions called by the given program parts , the system also traces the functions called by these Program (Parts). Only use the Restrict According to Definition in the Hotspot Monitor option if you are asked to by SAP Support.

Note

If you want to restore the standard settings, choose with the quick info text Standard Settings .

1.3.3 Executing Measurements

Use

Column Name Description

Program Type You can enter one of the following:

P for an executable program or module pool C for a global class

F for a function group

Program/Gl. Class/Fct. Group Name of the program, global class, or function group.

Local class Name of the local class to be measured.

Procedure Type You can enter one of the following:

METH for methods FUNC for function modules FORM for subprograms

Procedure Name of the procedure to be measured.

Use

Here are four ways to start a measurement with the ABAP Runtime Analysis: Executing a Trace in Dialog

Executing a Trace of a Parallel Work Process Scheduling a Measurement: The ABAP User Trace Executing a Measurement in the New ABAP Debugger

1.3.3.1 Executing a Trace in Dialog

Procedure

Use this procedure to run a program or transaction interactively. You can call the operations you want to trace. You can also turn the trace on and off interactively. 1. On the In Dialog screen area, choose between one of the following:

Transaction Program: Function Module

2. In the corresponding input field, enter the name of the transaction, program, or function module to be measured.

3. To have the measurement results displayed automatically after you end the measurement, select the Eval. Immediately checkbox.

If you do not select this checkbox, then the measurement waits for you on the Evaluate tab. In this case, you can execute a second measurement immediately.

4. Choose Execute .

Perform the actions in the transaction or program that you want to trace.

You can turn the trace on and off yourself to capture only part of the program in the trace. You must have selected this option in the variant, otherwise the trace starts automatically when you click Execute .

5. End the trace by leaving the transaction or report normally, with the Back or Exit button.

1.3.3.2 Executing a Trace of a Parallel Work Process

Procedure

Use this procedure to switch an analysis on and off in another work process on this or another server in the local system.

1. To have the measurement results displayed automatically when you finish the trace, select the Eval. Immediately checkbox in the In Parallel Session frame.

2. Choose Switch On/Off .

A dialog box appears containing all work processes on the current server. You can now activate the runtime analysis in one or up to ten work processes. You can activate the runtime analysis in all type of work processes, for example, a dialog, a batch, or an update.

It makes sense to activate the measurement for a program that has been running for a long time (for example, a batch job) that is already active on a work process.

You can also reserve a work process temporarily using the report RSTRC000. Programs that you start are then run in the locked work process so that by activating the measurement you can evaluate the programs in a targeted way.

This procedure for measuring an interactive program only makes sense if you also want to create a dev_wp* trace at the same time using RSTRC000. 3. To start the measurement, place the cursor on a work process and choose ( Activating a Measurement ), or simply double-click the work process.

The work process display shows in which work processes the runtime analysis has been initialized and is waiting for a program to be measured. The display also shows which traces are active.

A new trace file is started if a new program context (internal mode) comes into a work process. The runtime analysis is deactivated and the file is closed if the mode leaves the work process again.

4. To create a short description for the measurement, choose ( Short Description) .

A dialog box appears in which you can enter a description. This name appears in the performance data file overview. 5. For every external process, you can view details by choosing ( Choose Details ).

6. If the measurement has not ended automatically, you can terminate the measurement yourself. Place the cursor on a mode for which a measurement is running and choose (Deactivate Measurement ) or simply double-click the process.

If the Runtime Analysis reports that it cannot deactivate a measurement, either try the deactivation again, or choose the Cancel button on the message window. Cancel forces the Runtime Analysis to stop the measurement. You can still display the measurement after canceling it.

If you have reserved a work process using RSTRC000, ensure that you release it again with the report.

1.3.3.3 Executing a Measurement in the New ABAP Debugger

Procedure

You can start a measurement from the new ABAP Debugger. For example, you can trace program execution between two breakpoints in the debugger. Here is the procedure for switching a measurement on and off in the new Debugger.

1. Choose the New Tool button from the toolbar at the side of one of the debugger windows.

Prerequisite: Control is in the debugger session - for example, the program has stopped at a breakpoint in the debugger session. The Debugger displays the New Tool window for selecting from the available tools.

2. Open the Special Tools folder and choose the Trace (SE30/ST05) function. The ABAP Debugger adds the Trace Management tool to your debugger desktop tab.

3. Next to the entry for Trace Type ABAP Trace (SE30) , doubleclick the function in the On/Off column. The Status icon changes from to to show that the trace is running.

4. Run the program farther in the debugger until you want to end the trace.

5. In the Trace Management tool, double-click the icon in the On/Off column to stop the trace.

If the trace was successful, you can double-click the icon in the Trace File column to start transaction SAT and view the trace file. If the debugged program finishes before you turn off the trace, then you find the trace in Status Measurement Running in transaction SAT. End the trace and display it by choosing Process Measurements in the Evaluate tool bar.

If the Runtime Analysis displays the message Trace file not yet written. Do you want to wait? then choose the Cancel button to terminate and display the trace.

1.3.3.4 Scheduling a Measurement: The ABAP User Trace

Procedure

By scheduling a measurement, you tell the Runtime Analysis to start the measurement automatically, when the conditions that you specify are met. Here is the procedure:

1. On the For User/Service screen area, choose For User/Service . A dialog box appears containing all the scheduled measurements.

Measurements that have not been finished yet have the status In Process . Completed measurements have the status Executed .

By default, you see only measurements scheduled on the local server. Choose Server Selection from the tool bar to see scheduled measurements from other or all servers in the system.

2. Choose ( Schedule Measurement ).

The Schedule Measurement dialog box appears.

Enter all required information (see below). You can leave fields like User blank if you are not sure which user will start the activity you want to trace. Be as specific as you can so that you catch the activity that you want to measure.

If a measurement is not executed as planned, repeat the scheduling and set the scheduling parameters External Mode , Process Type , and Object Type to the value Any.

3. Choose Schedule (Measurement) to confirm the scheduling request.

The system schedules a measurement for the specified external mode, process type, object type, object name, time, and date. The request appears in the Overview of Scheduled Measurements with the Status In Process and the value 0 in the Started column.

When the trace or traces have been made, the Status changes to Executed . The Started column shows the number of traces that have been made. You must refresh the display to see changes in the Overview .

If an application server is shut down, then any scheduled measurements In Process (not yet completed) are lost.

You can also manage scheduled measurements actively. If a measurement is not needed, you can delete it in the Schedule Measurement dialog box.

Note

Enter service paths to measure BSP and Web Dynpro applications, as well as Web services.

You can measure specific types of HTTP requests by selecting URL as Object Type . You can then enter the path of the service in the Object Name field. You need only enter the URI, the path of a service in the Object Name field, not a complete URL. Start the path with the '/' character.

Figure 1: Using URL paths to schedule a BSP or Web Dynpro application or Web Service for runtime analysis.

You can display the path of a Web Dynpro application in the ABAP Object Navigator ( SE80) or in transaction SICF ( Services Maintenance ). You find the path of ABAP Web Services in the Enterprise Services Browser in the ABAP Object Navigator ( SE80) or in transaction SICF ( Services Maintenance ).

You find the path of a BSP application in transaction SICF ( Services Maintenance ).

Note

Starting HTTP measurements from transaction SICF

You can also start the runtime analysis for processing an HTTP request directly from transaction SICF ( Services Maintenance ): 1. In the Service Name field, enter the name of the service.

2. Display the service using Execute .

3. Select the service name and choose Edit Runtime Analysis . The system displays the scheduling window for the runtime analysis. Further Information on the Scheduling Fields

User

In the User field, enter the user under whose name the event to be measured will run.

The name specification is optional. If no user is entered, then the scheduled measurement ignores the user. The measurement is made for any user action that meets the other criteria.

Client

The specification of the client is also optional and serves to uniquely identify the user. (users MAIER/000 and MAIER/100 may possibly be assigned to different persons).

Leave Client blank to capture activity in any client. Note that you must log on in the client in which a measurement was made to display the measurement. Example: Assume that you schedule a measurement while you are logged in on client 100 and that a measurement is made on client 000. The Scheduled Measurements display in client 100 shows in the Started column that a measurement has been made. But you must log on to client 000 to see the measurement in transaction SAT on the Evaluate tab.

External Session

To make a measurement in another external session of your log on or another user's logon, specify the number of the session.

Example: to trace activity in another user's external session (SAP window) number 2, enter the user name, client (if needed) and External Session 2. When the user starts the activity in that session, the Runtime Analysis records it.

Otherwise, leave the field set to Any. Process Type

In addition to the ANY option, you can specify the following types of processes: Dialog Update Background processing RFC HTTP SMTP ITS

Shared Objects Area Constructor Object

The object to be measured can also be arbitrary, or one of the following types. Remember, however, that only certain combinations of Process Type and Object make sense.

Transaction (starting a transaction) - suits dialog, background processing Report (calling a program) - suits dialog, update, background processing

Function module (calling a function module / RFC) - suits dialog, update, background processing, RFC Shared Objects Area Constructor (setting up a shared objects area) - suits Shared Objects Area Constructor URL (calling a URL through ITS or HTTP) - suits HTTP, SMTP, ITS

Object name

The object name is also optional and specifies the name of an object of the selected type.

Here you need only enter a prefix - that is, the specification F1 for a report would mean that each execution of a report whose name begins with F1 can be measured.

To capture an HTTP request, only the path of the request is needed. (See the note above). Expiration Date and Expiration Time

The maximum number of planned measurements specifies how many measurements are to be created. The expiry date and time serve to limit the validity of the planned measurement. As soon as the maximum number of measurements of the expiry time has been reached, the status for planning is set to "finished".

Note

Try to avoid setting the expiry date for a planned measurement far into the future and choosing too large a number of executions. This could have a negative influence on system performance. This is particularly true when the measurement parameters are generic (arbitrary user, arbitrary process type).

Make sure that each started measurement is also finished. One common reason why a planned execution does not seem to be functioning is because a previous measurement is still active. You can check this by displaying the external processes, for example (using the function Switch On/Off in a parallel session).

1.4 Performance Results

Use

Choose the Evaluate to display an overview of the available messages and to choose trace files for a continuing analysis or a comparison.

Features

The following information is displayed for each measurement: Status

This column indicates the quality of the measurement. The column can contain one of the following:

If the column contains ( Measurement without Errors ), the measurement is relevant and suitable for analysis.

If the column contains ( <percentage> Load/Generation Times ), the load or generation times for programs or screens exceed 5% of the total runtime. The measurement is not suitable for performance analysis and should be repeated.

The quick info text Incomplete (Size Restriction) means that the measurement was canceled because the size or runtime restrictions in the variant were violated. Howver, the measurement can still contain useful information for you.

If the column contains ( Measurement with Errors ), the measurement could not be ended correctly, or has a corrupt hierarchy. It is not possible or not reasonable to display it. The measurement must be repeated.

If the column contains ( Measurement not yet formatted ), the measurement is not converted in the runtime analysis format. The system converts it when you display it.

To format measurements automatically, on the Measr. tab select Eval. Immediately . The Measurement Date and Measurement Time .

A Short Description of Runtime Measurement and the Name of Trace Object . Trace User

Runtime [Microseconds] Aggregation type

System Functions

Refreshing the Display

If you choose ( Refresh Display ), the system searches for newly created traces, for example by other users, or in an asynchronous process, and refreshes the list of traces.

Display measurement

If you choose ( Display Measurement ), the selected trace file is displayed in another screen. For more information, see Measurement Display.

Display Measurement as UML

If you choose , you can display the call hierarchy as a UML Diagram for measurements without aggregation. Change Short Description / Change Expiry Date

If you choose ( Change Short Description ), you can edit the short description text for the selected trace file. With the Change Expiry Date function you can extend or move up the pre-defined date for deleting traces.

Details

If you choose ( Details) , the measurement details are displayed in a dialog box. Internal and External Time Consumption

If you choose ( Intern./Extern. Time Consumption ), the system displays a graph of the internal, external, and total time consumed.

ABAP events can consume CPU time on the current application server where the measurement has been started, or on an external resource, for example, as an SQL statement on the database server, or as a remote call on a remote machine. You use this function to see if a large fraction of the total runtime was spent on an external resource.

Delete Measurement

If you select a measurement and choose ( Delete Measurement ), the system deletes the measurement from the database. Compare Measurements

If you want to compare two measurements, select them and choose ( Compare Measurements) . Choose one of the following options: Compare Hit Lists

The Hit List Comparison tool appears.

You choose this function to compares the hit lists of two measurements to identify nonlinear coding. Compare Call Hierarchies

The Hierarchy Comparison tool appears.

You choose this function to identify the variation in the execution of a program in two different runs. This is applicable only to measurements executed without aggregation.

Send Measurement via RFC

If you choose ( Send Measurement Using RFC ), you can send a measurement to another system. With this function you can, for example, compare the performance of a program on two different servers.

It is required that the other system has SAP_BASIS 7.00 or higher. Switch to Trace Server

If you choose the Switch to Trace Server or Switch to Trace Server function, the runtime analysis is started on the server for you where the selected message was created.

Import or Export Measurement

If you choose ( Import Measurement ) or with the quick info text Export Measurement , a trace file of the runtime analysis -Datei der Laufzeitanalyse in eine auf Ihrem Rechner abgelegte XML-Datei geschrieben bzw. aus einer solchen gelesen. With these functions you can store runtime measurements in the file system or bring measurements from different servers together and compare them.

Selecting Layouts

If you choose ( Select Layouts... ), you can personalize the fields displayed in the measurement overview. Standard Mode and Expert Mode

If you are in standard mode and choose ( Expert Mode ), the system displays the following additional columns: % Internal

Contains the internal time consumption as a percentage Size [Bytes]

Release Operating System Computer

If you are already in expert mode, choose ( Standard Mode ) to hide the additional columns.

1.4.1 Adapting Message Display

Use

You use the display control functions of the ABAP Workbench to configure the measurement display interface according to your needs and requirements. If you save your personal layout on the Desktop 1 or Desktop 2 tabs with Application Save Layout sichern, then it is available to you every time you start the runtime analysis.

Features

A measurement display can contain at least one and at most four tools. You can display one tool more than once within the same measurement display. Tools can be resized and swapped across the screen.

Tools Arrangement

You can add a new tool to the display by choosing ( New Tool ). The New Tool dialog box appears.

The function is available if you have less than four tools displayed. You close the tool by choosing ( Close Tool ).

You can replace the tool with another by choosing ( Replace Tool ).