Analysis Tools - Runtime Analysis

Runtime Analysis
PDF download from SAP Help Portal:
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
PUBLIC
© 2014 SAP AG or an SAP affiliate company. All rights reserved.
Page 1 of 28
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
PUBLIC
© 2014 SAP AG or an SAP affiliate company. All rights reserved.
Page 2 of 28
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
PUBLIC
© 2014 SAP AG or an SAP affiliate company. All rights reserved.
Page 3 of 28
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.
PUBLIC
© 2014 SAP AG or an SAP affiliate company. All rights reserved.
Page 4 of 28
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.
PUBLIC
© 2014 SAP AG or an SAP affiliate company. All rights reserved.
Page 5 of 28
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.
PUBLIC
© 2014 SAP AG or an SAP affiliate company. All rights reserved.
Page 6 of 28
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.
PUBLIC
© 2014 SAP AG or an SAP affiliate company. All rights reserved.
Page 7 of 28
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.
PUBLIC
© 2014 SAP AG or an SAP affiliate company. All rights reserved.
Page 8 of 28
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.
PUBLIC
© 2014 SAP AG or an SAP affiliate company. All rights reserved.
Page 9 of 28
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
PUBLIC
© 2014 SAP AG or an SAP affiliate company. All rights reserved.
Page 10 of 28
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.
PUBLIC
© 2014 SAP AG or an SAP affiliate company. All rights reserved.
Page 11 of 28
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.
PUBLIC
© 2014 SAP AG or an SAP affiliate company. All rights reserved.
Page 12 of 28
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
PUBLIC
© 2014 SAP AG or an SAP affiliate company. All rights reserved.
Page 13 of 28
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
PUBLIC
© 2014 SAP AG or an SAP affiliate company. All rights reserved.
Page 14 of 28
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 ).
PUBLIC
© 2014 SAP AG or an SAP affiliate company. All rights reserved.
Page 15 of 28
The New Tool dialog box appears.
You can display a tool in full screen, closing all other tools, by choosing ( Full Screen ).
A tool is always displayed in full as long as the measurement display does not contain other tools.
The function is available if you have more than one tool displayed.
You can maximize the selected tool vertically by choosing ( Maximize Vert. ).
If you have four tools displayed, the tool below or above the one that is vertically maximized is closed.
The function is available if you have more than one tool displayed.
You can maximize the selected tool horizontally by choosing ( Maximize Hor. ).
If you have four tools displayed, the tool to the left or to the right of the one that is horizontally maximized is closed.
The function is available if you have more than one tool displayed.
You can swap tools that are already displayed by choosing ( Swap... ).
If you have three tools displayed, a dialog appears asking you to Swap Vertically or to Swap Horizontally .
If you have three tools displayed, a dialog appears asking you to Swap Vertically , to Swap Horizontally , or Swap Diagonally .
The function is available if you have more than one tool displayed.
Tools Size
Using the Increase and Reduce pushbuttons, you can resize tools by performing the following: You can:
Adjust the horizontal separation line.
Adjust the vertical separation line.
Saving layout
You can rearrange and resize tools in each of the measurement displays, but you can permanently save only the layout of Desktop 1 and Desktop 2 .
For this, choose ( Save Layout ). The layout setting you have saved appears the next time you start the runtime analysis.
1.4.2 Measurement Display Tool
Use
The display control for measurements provides you with a series of tools with which you can check the different aspects of a measurement more closely, for
example, the hit list of the programs that use the most runtime, or the activity on the database.
The views of these tools can be chosen individually using the Measurement Display tab. As in the new ABAP Debugger, you can activate, deactivate, and
combine display tools as required flexibly on the desktop of the runtime analysis.
Features
You can choose the different tools from the tabstrip below the Program Information screen area.
All tabs show the standard tool in the standard size. You can adjust every tool individually to suit you.
The default tools for Desktop 1 and Desktop 2 are the following:
Profile and Hit Lists for Desktop 1
Processing Blocks and Call Hierarchy for Desktop 2
You can adapt and save the layout of Desktop 1 and Desktop 2 . It is then available to you every time you start the runtime analysis.
For more information about redesigning a measurement display, see Customizing the Display.
Depending on whether you have executed the measurement by aggregated by call or without aggregation, the following displays are available:
Functions
Saving Layouts
You can adapt and save the layout of Desktop 1 and Desktop 2 permanently. For this, choose ( Save Layout ).
The layout settings that you have saved appear the next time you start the runtime analysis.
Special Selection
If you choose ( Special Selection ), a dialog box appears in which you can restrict the number of entries displayed according to different filter options.
Two of these options are Without DB Times and Without System Programs . With this you can exclude external times that have elapsed on the DB server
or in the system programs.
You can also use a SLAD object set or a SLAD profile to filter measurement entries. See Display Filters on this.
Restore Complete View
If you choose ( Restore Whole View) , the filters are deleted.
1.4.2.1 Hit Lists
Aggregation Available Displays
None Desctop1
Desktop2
Hit Lists
Database Tables
Profiles
Processing Blocks
Call Hierarchy
Times
Per Call Position Desctop1
Hit Lists
Database Tables
Profiles
Times
PUBLIC
© 2014 SAP AG or an SAP affiliate company. All rights reserved.
Page 16 of 28
Use
You use the Hit List view to display a hit list of all of the measured statements within a transaction, ABAP program, or function module. The hit list represents an
aggregated view of the events. You can use it to see time-intensive events.
Identical events are summarized into one line. The number of executions, the gross and the net times are summed up. The hit list discriminates between identical
events from different calling positions. If one statement is called from different ABAP programs, or from the same ABAP program but from a different position in the
source code, this leads to different entries in the hit list.
Features
The following information is displayed for each entry in the hit list:
Hits
This is the number of executions of a statement.
Total time
The total time required for a call. This includes the runtime of all modularization units and ABAP statements called by the subject.
The hit list displays the gross time as an absolute value and as a percentage.
The entire hit list is sorted descending according to the gross time.
Net Time
The net time is the part of the runtime for which a measured event is directly responsible. The net time is the gross time less the time required for
modularization units for example (MODULE, PERFORM, CALL FUNCTION, CALL SCREEN, CALL TRANSACTION, CALL METHOD, CALL DIALOG,
SUBMIT), and for the ABAP statements listed separately. For statements such as APPEND, the gross time is the same as the net time.
The hit list displays the sum of the net times as an absolute value and as a percentage.
Statement
The column displays the operation and the individual statement.
Called/Calling Program
These columns contain the name of the program where a measurement event has taken place or the name of the program that called the called program.
Program Offset (optional) (optional)
This field is an internal position counter for distinguishing between different calling positions in a program.
Functions
Hierarchy Field Division
If you choose ( Statement/Event Display ), a dropdown box appears in which you can choose between the following display options:
Hierarchy Field Divided
The function splits the Statement/Event column into the following columns:
Operation
The column contains the event type.
Operand
The column contains the event name.
Program Called
The column contains the executed program.
Hierarchy Field Compact
The function merges columns Operation , Operand , and Called Program into one column.
Example
If you choose the option Divided Statement Field for the statement/event field Call M. MyClass=>MyMethod, then Call M.=> is displayed
in the Operation column, MyMethod in the Called Program column, and MyClass======================CP in the Operand column.
Additional Information
If you choose ( Additional Information ), a dropdown box appears in which you can choose to assign a statement to a group entity, such as a program,
package, or person responsible.
Display Source Code
If you choose ( Display Source Text ), you jump to the ABAP source text.
Display Subarea
If you select a line and choose ( Display Subarea ), the line is displayed in the Times view.
You use this function to see detailed information for the current statement.
Position
If you choose ( Position Cursor ), a dropdown box appears from which you can navigate to one of the following tools:
Position in the Times Tool
With this function you can display the aggregated statement or events of the hit list in the individual entries of the time list.
Position in the Hierarchy Tool
With this function you can define where the individual statements or events of a hit list aggregation appear in a measured program (only for
measurements without aggregation).
Position in the Processing Blocks Tool
With this function you can define in which modularization units the individual statements or events of a hit list aggregation appear in a measured
program (only for measurements without aggregation).
1.4.2.2 Database Tables
Use
You use DB Tables display mode to identify time-consuming database statements. The hit list shows tables accessed during the trace run. You also use it to
identify accesses to buffered tables.
PUBLIC
© 2014 SAP AG or an SAP affiliate company. All rights reserved.
Page 17 of 28
Features
The following information is displayed for each table entry:
Table Name
Access Mode
Accesses
The number of accesses to the table. The system counts the OPEN and CLOSE-CURSOR operations that are implicitly part of SELECT statements.
Gross time
Internal Net Time
The column Net (int) contains the time spent in the SAP table buffers or the database interface.
External Net Time
The column Net (ext) contains the time spent on the database sever.
Note
If the external net times are high, the user should run the Performance Analysis (transaction code ST05) to examine the database statements more
thoroughly.
Buffering
This column can contain the following values that correspond to the technical settings of the table in the Data Dictionary:
Empty
The table is not buffered
On
The table is buffered.
Off
Table buffering is allowed but is switched off.
Cust
The table is not buffered but could be buffered because it is defined as a table that can be defined by the user.
Note
Tables with high external net times and Buffering equal to Cust. or Off should be allowed for buffering.
Buffering Types
The column can contain the following values:
Single Record
Generic
Complete
Table Type
Pool/cluster Name
Description
Package
Functions
Display DDIC
If you choose ( Display DDIC ), the system jumps to the DDIC for the selected table.
Absolute and Percentage Times
If you choose ( Absolute/Percentage Times ), the system toggles between displaying the times as an absolute value or as a percentage of the total
time.
Change Summarization
If you choose ( Change Summarization ), a dropdown box appears in which you can choose between the following summarization levels of the DB list:
Aggregation: Tables
For every table there is a single entry in the list.
Aggregation: Statements
For different DB statements, such as SELECT, SELECT SINGLE, INSERT, UPDATE, MODIFY, DELETE, there is a single entry per table.
Aggregation: DB Operations
The SELECT statements are divided into OPEN CURSOR, FETCH, and CLOSE CURSOR.
Position
If you choose ( Position Cursor ), a dropdown box appears from which you can navigate to one of the following tools:
Position in the Times Tool
Position in the Hierarchy Tool
Position in the Hit List Tool
Position in the Processing Blocks Tool
The system opens the selected entry in the relevant tool.
1.4.2.3 Profiles
Use
You use the Profile display to get an overview of the trace. You use it to sum up identical event types, group them together into event groups, and to build
classes of groups. This creates a multilevel event hierarchy. Execution and net times are added together. However, gross times cannot be added together.
Alternative profiles allow grouping of events according to packages, components, or programs.
Features
For each entry in the Profile tree, the following information is provided:
PUBLIC
© 2014 SAP AG or an SAP affiliate company. All rights reserved.
Page 18 of 28
Profiles
Name of the item grouped in the profile
Selection
The checkbox allows you to select different profile items to filter the hit list accordingly.
Number
Number of calls of one event group.
Net [µs]
Summarized net time for all events of one event group.
Net [%]
Functions
Other Profile
To toggle between profiles, choose ( Switch Hierarchy ). You can choose between the following profiles:
Trace Events
Packages
Components
Programs
Display Subarea
You can choose one or more nodes from the tree and display it in another tool to view more detailed information. Select ( Display Subarea ) for this.A
dropdown box appears in which you can choose one of the following:
Display Subarea in Hit List Tool
Display Subarea in Times Tool
1.4.2.4 Processing Blocks
Use
You use the Processing Blocks display to present the call hierarchy in a tree. Processing blocks are represented by nodes that you can open to view the blocks
lying on a lower hierarchy level.
Features
The following information is provided for each processing block:
Processing Block
domain
System
For system programs the column contains with the quick info text System Time .
Gross (time)
Net (time)
Functions
Refresh Tree
You can refresh the display by choosing with the quick info text Refresh Tree Display .
Find
You can search the tree for a given term and open the first node where it was found by choosing with the quick info text Find... .
The system colors the corresponding processing block in green.
Critical Nodes
If you choose with the quick info text Critical Nodes , a dropdown box appears in which you can choose between the following:
Net Times
Gross Times.
Memory Consumption
For this, define the threshold value for the selected option as a percentage value for the critical node.
The tree nodes that violate the threshold value are highlighted in red and expanded.
Memory Use On/Off
Select to hide/show the aggregated memory use. This function is only available if you have activated the Measure Memory Use option in Measurement
Variant.
Using the memory use fields, you can see how much memory was allocated for a specific processing block, for which processing blocks the memory use
increased and decreased, and how much the modularization unit has changed by in a processing block of the memory use.
Absolute/Percentage Times
You can toggle between absolute times and percentages by choosing with the quick info text Absolute/Percentage Times .
Confine to Subarea
You can restrict the work area by selecting ( Restrict to Work Area ).
This confines the data in all tools to the statements that lay in the subhierarchy of the selected node.
You use this function if you want to focus on a specific subhierarchy.
Position
If you choose ( Position Cursor ), a dropdown box appears from which you can navigate to one of the following tools:
Position in the Times Tool
Position in the Hierarchy Tool
Position in the Processing Blocks Tool
1.4.2.5 Call Hierarchy
Use
PUBLIC
© 2014 SAP AG or an SAP affiliate company. All rights reserved.
Page 19 of 28
Use
You use the Call Hierarchy to display the measurement events the way they were called by the program. You also use it to identify time-consuming events by
examining the net and gross times that each event consumed.
Features
The following information is displayed for each hierarchy entry:
Index
The index of the trace hierarchy entries.
domain
Call stack level of the statement.
Statement
Event Name
Gross [µs] Time
Net [µs] Time
Memory (Optional)
You can only display this field if the applied measurement variant includes memory measuring.
Note
The fields Memory and Gross Memory Usage Increase refer to the start and end of the trace event. They cannot simply be read sequentially as they
appear in the display.
The Memory field specifies the size of the whole memory allocated by the internal mode. The value is read when entering a trace event. For example,
the memory consumption for a call function event in the trace is measured when entering the function module before the stack is built.
The Gross Memory Usage Increase specifies the difference between the memory size at the start and at the end of a trace event. The memory
consumption at the start of the event is shown in the Memory field. The runtime analysis measures the memory consumption at the end of the event
again. For example, the memory usage increase for a call function event specifies the difference between the value in the Memory field and the
memory consumption when exiting the function module after the stack has been built.
Use the function to switch between the start and end of a trace event. In this way you can find the actual memory consumption increase as a result of
the event.
Use the function to jump one level higher in the call hierarchy.
Functions
Create View
If you choose ( Create View ), a dropdown box appears from which you can choose one of the following display options:
Only Processing Blocks
The system displays in the hierarchy only the opening or closing events of the processing blocks.
All Runtime Events
This is the default setting.
Confine to Subarea
If you select an entry and choose ( Confine to Subarea ), you can confine the data to the statements that lay in the subhierarchy of the selected entry.
Restore Complete View
If you have restricted the work area, then you can choose ( Restore Whole View ). The system displays the original call hierarchy.
Goto Corresp. Record
If you choose ( Goto Corresp. Record ), you jump to the opening or closing events of the selected statement.
Goto Caller
If you choose ( Goto Caller ), the system jumps to the statement on the next higher hierarchy level from which the selected statement has been called.
Additional Information
If you choose ( Additional Information ), a dropdown box appears in which you can choose to assign a statement to a group entity, such as a program,
package, or person responsible.
Memory Consumption On/Off
If you choose ( Memory Consumption On/Off ), the system displays the memory consumption of the measured programs in a new column. This is
only possible if the measurement variant was set appropriately.
Absolute/Percentage Times
If you choose ( Absolute/Percentage Times ), the system toggles between displaying the times as an absolute value or as a percentage of the total
time.
Scrolling
If you choose ( Scroll ), a dropdown box appears from which you can navigate to one of the following tools:
Goto First Line
Goto Last Line
Display Call Stack
If you choose ( Display Call Stack ), the call stack of the selected statement is displayed.
Display Source Code
If you choose ( Display Source Text ), the ABAP source text of the selected statement is displayed.
Position
If you choose ( Position Cursor ), a dropdown box appears from which you can navigate to one of the following tools:
Position in the Times Tool
Position in the Hit List Tool
Position in the Processing Blocks Tool
1.4.2.6 Times
PUBLIC
© 2014 SAP AG or an SAP affiliate company. All rights reserved.
Page 20 of 28
Use
You use the Times view to display more specific time measurement values for the single events of the hierarchy.
Features
For each entry in the Times hit list, the following information is displayed:
Index
The system displays the index of the hierarchy entries. Closing events are not shown.
Statement
Gross time [µs]
Net [µs] Time
User Times Total
The column contains the runtime consumed by non-system programs
System Times Total
The column contains the runtime consumed by system programs.
In the expert mode, the system displays additional time fields. Some of these are the times spent in system and non-system programs belonging to processing
blocks, database interface, database, internal tables, and screens.
Functions
Scrolling
If you choose ( Scroll ), a dropdown box appears from which you can navigate to one of the following tools:
Goto First Line
Goto Last Line
Hierarchy Field Division
If you choose ( Statement/Event Display ), a dropdown box appears in which you can choose between the following display options:
Hierarchy Field Divided
The function splits the Statement/Event column into the following columns:
Operation
The column contains the event type.
Operand
The column contains the event name.
Program Called
The column contains the executed program.
Hierarchy Field Compact
The function merges columns Operation , Operand , and Called Program into one column.
Example
If you choose the option Divided Statement Field for the statement/event field Call M. MyClass=>MyMethod, then Call M.=> is displayed
in the Operation column, MyMethod in the Called Program column, and MyClass======================CP in the Operand column.
Additional Information
If you choose ( Additional Information ), a dropdown box appears in which you can choose to assign a statement to a group entity, such as a program,
package, or person responsible.
Display Source Code
If you choose ( Display Source Text ), you jump to the ABAP source text.
Absolute/Percentage Times
If you choose ( Absolute/Percentage Times ), the system toggles between displaying the times as an absolute value or as a percentage of the total
time.
Standard Mode and Expert Mode
If you are in standard mode and choose ( Expert Mode ), the system displays additional columns with special times:
If you are already in expert mode, choose ( Standard Mode ) to hide the additional columns.
Position
If you select a row and choose ( Position Cursor ), you can navigate to the current entry in one of the following tools.
Position in the Hit List Tool
With this function you can display the aggregated time usage of the statement or event in the hit list.
Position in the Hierarchy Tool
With this function you can define where a time entry appears in the call hierarchy (only for measurements without aggregation).
Position in the Processing Blocks Tool
With this function you can define in which modularization unit a time list entry appears (only for measurements without aggregation).
1.4.3 Comparison Tools
Use
You use the comparison tools to analyze in detail the behavior of the program you are measuring. The runtime analysis has the following compare tools:
Hit List Comparison
You use this tool to check a measurable component for nonlinear coding.
Hierarchy Comparison
You use this tool to identify new branches in the program execution.
Integration
PUBLIC
© 2014 SAP AG or an SAP affiliate company. All rights reserved.
Page 21 of 28
The Hit List Comparison and call Hierarchy Comparison tools are part of the functionality of the Evaluation tab page.
To start the hit list comparison, select two measurements and choose with the quick info text Compare Measurements .
From the dropdown box, choose Compare Hit Lists .
To start the hierarchy comparison, select two measurements and choose with the quick info text Compare Measurements .
From the dropdown box, choose Compare Call Hierarchies .
With this function, you can compare only measurements without aggegation.
Note
As of Release NetWeaver 7.0 EHP2, you can compare measurements across application servers - even if they have different operating systems - and
across systems.
If you export a measurement to file, it is held in a release-neutral (as of NetWeaver 7.02 EHP2) and host operating system-neutral format.
For example, you can compare execution of a program on an application server running under Linux and another running under Windows. You can compare
measurements from your test and production systems.
Prerequisites
You have prepared two measurements that adhere to the respective rules for comparing two traces.
For more information, see Hit List Comparison and Hierarchy Comparison.
1.4.3.1 Hit List Comparison
Use
You use the hit list comparison tool to identify differences in the hit lists of two traces. This functionality is useful if you want to check your programs for nonlinear
coding. You trace a program twice, the first time with a smaller amount of data, the second time with a larger amount of data. You use the same system and you do
not change the program code between the measurement of the two trace files.
Note
You also use the hit list comparison tool to see the effects on runtime if you change the code or the system. In this case you do not change the amount of data.
Prerequisites
You have prepared two sets of test data for tracing.
Recommendation
We recommend using a reasonable amount for the first measurement, and a larger amount for the second measurement. An increase by a factor of 10
between the two measurements is most convenient.
Before you perform the actual tracing, you have first executed the program to fill the buffers.
Recommendation
We recommend the following measurement restrictions in a variant definition:
On the Statements tab, select DB-level Ops. .
On the Duration/Type tab, select Aggregation by Call Position .
Features
Data Loading and Checks
After you have started the Hit List Comparison tool, the system loads the trace files and checks whether the following conditions are true:
The trace name and type must be identical, otherwise an error message appears.
The aggregation type should be identical, otherwise a warning message appears, but the comparison is continued.
The selected trace events must be identical, otherwise an error message appears.
Whether for older traces the aggregation type is full. In this case, the comparison of internal tables does not work.
Whether the trace measurement is executed in parallel for only one of the two traces. In this case, a warning message appears.
Whether only one of the traces was restricted to particular units. In this case, the system tests the settings of the units and an error or warning message
appears.
Comparison Process
After successfully loading the trace messages, a search is made in trace 2 for a line that corresponds to each line in trace 1. A match is only made when the
following attributes are identical for both lines.
Event class
The top level of the event hierarchy.
Event Type
Event Name
The name is not checked only for internal tables whose names are not used.
Calling program
Program where the call comes from.
PUBLIC
© 2014 SAP AG or an SAP affiliate company. All rights reserved.
Page 22 of 28
Offset
The line where the call is made. If the same event is called from two different positions in the code, the system regards it as two different events.
The hit list comparison tool automatically determines the order of the traces. The system by default assigns the trace with the larger net time to Trace 2.
1.4.3.1.1 Hit List Comparison Results
Use
You use the results to identify nonlinear coding. You must remember the factor by which you have multiplied the amount of data that was used in the trace. You
examine the results and check if the net time ratios are greater than the factor.
You also use the results to find program differences resulting from coding changes or hardware changes. In this case, you must examine the difference in net
times. However, a change in coding changes the control block offset for many lines in this program. Therefore the system finds more lines with no correspondence.
Features
Hit list
The following information is displayed for each event from the hit list:
Code
The column indicates to what extent the comparison was successful.
T12 indicates that the comparison was successful and the system has found two corresponding lines.
T1 indicates that the system found a line in Trace 1 that has no corresponding line in Trace 2.
T2 indicates that the system found a line in Trace 2 that has no corresponding line in Trace 1.
Event class
The column contains the name of the class to which the event belongs.
Event Type
The column contains the type of the event.
Event Name
Times and Number of Executions
If the comparison was successful, the following columns contain the results:
The ratio or the difference of net times, the net time of events in Trace 2, and the net time of events in Trace 1.
The ratio or the difference of the number of executions, the number of executions of events from Trace 2, and the number of executions of events from
Trace 1.
The ratio or the difference of gross times, the gross time of events from Trace 2, and the gross time of events from Trace 1.
Lines for which the system found no counterpart have only one value displayed in each group of columns.
Calling program
The column contains the name of the program that called the event.
Offset
The column contains the offset of the control block in the program code.
Program Called
If the event calls a program, the name of the program is displayed in the column.
Functions
The following functions are available on the application toolbar:
Display graphic
If you choose ( Display Graphic ), the contents of the table is shown as a graphic.
Swap Trace 2 with Trace 1
If you choose ( Swap Trace 2 with Trace 1 ), the system exchanges the basic trace, which is by default the trace with the larger runtime.
Display Source Code
If you choose ( Display Source Code ), the system displays the location in the ABAP source code where the event is called.
Initial Sorting and Layout
If you choose ( Initial Sorting and Layout ), the system restores the initial sort order and layout of the hit list comparison.
With Differences or With Ratios
You can choose to display the comparison between the net time, gross time, and execution number as a ratio or difference.
To display the difference, choose ( With Differences ).
To display the ratio, choose ( With Ratios ).
Navigation
From the hit list comparison, you can navigate to the following displays:
Individual Lines
To navigate to this display, choose Individual Lines .
Event Hierarchy
To navigate to this display, choose Events .
Programs hit list
To navigate to this display, choose Programs .
1.4.3.1.1.1 Individual Lines
Use
You use the function to filter and reorder the hit list to display only the lines that have no corresponding line. The order of the columns and the sort order of the lines
is different to the hit list. You use this view to manually find lines that belong together, but are not identified automatically because they differ in name or offset.
PUBLIC
© 2014 SAP AG or an SAP affiliate company. All rights reserved.
Page 23 of 28
Features
For each event, the following information is available:
Event Class and Event Type
Calling program
The column displays the name of the program that called the event.
Offset
The column contains the offset of the control block in the program code.
Program Called
The column contains the name of any program that is called from the event.
Code
The column indicates to which trace the event belongs:
If T_1 is displayed, the event belongs to Trace 1.
If T_2 is displayed, the event belongs to Trace 2.
Event Name
Net time
Depending on which trace the event belongs to, its net time is displayed either in column Net 2 or in column Net 1 .
Number of executions
Depending on which trace the event belongs to, its number of executions is displayed either in column No. 2 or in column No. 1 .
Gross time
Depending on which trace the event belongs to, its gross time is displayed either in column Gross 2 or in column Gross 1 .
Navigation
From the Individual Lines display, you ca navigate back to the hit list comparison by choosing ( To Hit List ).
1.4.3.1.1.2 Event Hierarchy
Use
You use the Event Hierarchy to display an overview of the program. You use a display, organized in event classes, to achieve a aggregated view.
The system aggregates event types into event groups and the event groups into event classes.
Features
The following information is available for each type of event:
Event class
The event classes are the top level of the hierarchy and are divided into the following types:
A Modularization units internal
The event class summarizes the effect of ABAP coding inside the application server.
B Modularization units external (RFC)
The event class summarizes the effect of coding processed via RFC.
C Internal tables
Internal tables are listed separately as they not used in the default setting.
D Internal Storage
The event class shows the effects related to data storage inside the application server.
E External Storage
The event class shows the effects related to data storage inside the database.
X Others
The event class contains all other events that are not under your direct control.
Z Runtime analysis
The event class contains the time that the Runtime Analysis used. The time measured is small, except if the tracing is restricted to particular units.
The percentages are calculated based on the whole time. The percentages are calculated from the total including the contributions that are not traced
by particular units. The event class also contains load and generation times and undefined events.
The net times of the event class in Trace 1 and Trace 2.
The net times as a percentage.
The number of executions of the event class in Trace 1 and Trace 2.
The number of lines in Trace 1 and Trace 2.
Functions
You use the following functions to switch between the three levels of the event hierarchy.
There are always two functions active. The level that is displayed cannot be called.
Event Classes
If you choose Event Classes , the system displays the top level of the hierarchy containing the event.
Event Groups
If you choose Event Groups , the system displays the middle level of the hierarchy containing the event.
Event Types
If you choose Event Types , the system displays the lowest level of the hierarchy containing the event.
Navigation
From the Event Hierarchy, you can navigate to the following displays:
Hit List Comparison
To return to the Hit List Comparison, choose ( To Hit List ).
Limited hit list
PUBLIC
© 2014 SAP AG or an SAP affiliate company. All rights reserved.
Page 24 of 28
You can display only a selected row of the Event Hierarchy in the hit list comparison. Choose (Restrict Hit List ) for this.
Program Hit Lists
To navigate to this display, choose ( Program Hit List ).
1.4.3.1.1.3 Program Hit Lists
Use
You use the program hit list to aggregate the hit list according to programs. You use it to aggregate the net times of Trace 1 and Trace 2 for calling or called
programs
Features
The following information is available for each program:
The net times of the event class in Trace 1 and Trace 2.
The net times as a percentage.
Different attributes of the program.
The number of lines in Trace 1 and Trace 2.
Functions
You can choose between displaying the called program or the calling program. Depending on which display you are currently viewing, choose one of the following:
Program Called
To switch from the calling program to the called program, choose ( Called Program ).
Calling Program
To switch from the called program to the calling program, choose ( Calling Program ).
Navigation
From the program hit list, you can navigate to the following displays:
Hit List Comparison
To return to the Hit List Comparison, choose ( To Hit List ).
Event Hierarchy
To navigate to the results hierarchy, choose (To Results Hierarchy) .
1.4.3.2 Call Hierarchy Comparison Results
Use
You use the call hierarchy comparison results tool to identify new branches in the program execution that were not executed in a previous execution of the
program.
Features
The following information is displayed for each statement in the basic trace:
Index
The index of the basic trace hierarchy entries
domain
The number of the hierarchy level to which the statement belongs.
Statement
Total time
Net Time
Note
The headings of the hierarchy comparison indicate which trace is regarded as basic. The index, level, gross, and net time is displayed only for the
basic trace. The headings of the columns indicate in parentheses which trace is regarded as basic.
Coloring
To facilitate the hierarchy compare, the following coloring pattern is adopted:
Red
Statements that are in the basic trace, but not in the comparison trace.
Green
Statements that are in the comparison trace, but not in the basic trace.
No Color
Statements that can be found in both traces.
You can also change the list layout to display the Trace column. This column contains the color-coded information in a number format.
Functions
Goto Caller
If you choose ( Goto Caller ), the system jumps to the statement on the next higher hierarchy level from which the selected statement has been called.
Goto Corresp. Record
PUBLIC
© 2014 SAP AG or an SAP affiliate company. All rights reserved.
Page 25 of 28
If you choose ( Goto Corresp. Record ), you jump to the opening or closing events of the selected statement.
Display Call Stack
If you choose ( Display Call Stack ), the call stack of the selected statement is displayed.
Display Source Code
If you choose ( Display Source Text ), the ABAP source text of the selected statement is displayed.
Display options
If you choose ( Display Options ), a dropdown box appears in which you can choose between the following display options:
Time Proportions (Percent)
The system toggles between displaying gross and net time values in absolute numbers or as a percentage.
Show or Hide Indents
The system shows or hides the statement indention which reflects the level of the statement in the call hierarchy.
Delete '<' Events
The system deletes the closing events that are provided for every traced ABAP statement. This action is irreversible. To see the closing events again,
you must reload the trace. For large traces, the system automatically removes these events to reduce the volume of the trace.
Color Scheme Yellow/Blue
You can switch from red/green color scheme to the yellow/blue color scheme
Additional Information
If you choose ( Additional Information ), a dropdown box appears in which you can choose to assign a statement to a group entity, such as a program,
package, or person responsible.
Trace Aggregated/Complete
If you choose ( Trace Aggregated/Complete ), the system groups consecutive statements of one color into blocks of statements, displayed on a single
line.
Column No. of Trace Recs. shows how many statements have been condensed into one line.
The blocks cannot be expanded to see all statements inside them. It is possible to set the cursor on one block and then return to the full list. The cursor is
then positioned on the first statement of the block.
Note
Multiple statements are grouped into only one block, if all of them are on the same or on a deeper execution level compared to the first statement of the
block. For example, if a statement block that started on level 5 is followed by a statement of the same color on level 4, there are two adjacent blocks of
the same color.
Change Basic Trace
If you choose ( Change Basic Trace ), the system switches from Trace 1 as the basic trace to Trace 2, or vice versa.
Initial Sorting
If you choose ( Initial Sort ), the original sort sequence of the hierarchy comparison is restored.
Navigation
If you choose ( Next Additional Call ), the system goes to the next additional entry in the basic trace.
If you choose ( Next Identical Call ), the system goes to the next entry that is present in both traces.
If you choose ( Next Omitted Call ), the system goes to the previous additional entry in the basic trace.
If you choose ( Goto First Line ), the system goes to the first line of the hierarchy comparison list.
If you choose ( Goto Last Line ), the system goes to the last line of the hierarchy comparison list.
If you choose ( Last Additional Call ), the system goes to the last additional entry in the basic trace.
If you choose ( Last Identical Call ), the system goes to the last entry that is present in both traces.
If you choose ( Last Omitted Call ), the system goes to the last entry missing in the basic trace.
1.4.3.2.1 Hierarchy Comparison
Use
You use the call Hierarchy Comparison tool to identify new branches in the program execution that were not executed in a previous execution of the program.
Such different branches can be due to:
Differing program sources
Differing starting parameters, or custom data
Differing buffer state, which can lead to extra calls to fill buffers
Features
Data Loading and Checks
After you have started the call hierarchy comparison, the system loads the traces. If they have been measured with different measurement variants, an information
dialog appears, but a comparison is still possible.
1.4.4 Display Filter
Use
You can use the Display filter function to restrict the values that are displayed.
The contents of the lists that the runtime analysis displays depend on your filter settings. You can call this function in the overview screen using Utilities
Pre-Defned Filters on the overview screen of the runtime analysis or using the pushbutton.
Display options
With the display filter you can restrict the results that are displayed to both specific programs or trace events.
PUBLIC
© 2014 SAP AG or an SAP affiliate company. All rights reserved.
Page 26 of 28
Filtering programs: You can, for example, display performance results of a specific package, program, or class. You can restrict the display to an SLAD
Object Set.
Filtering trace events: You can exclude certain internal and external trace events from the meaurement display. You can, for example, exclude RFC calls and
the internal and external portions of DB operations.
The runtimes of performance results that have been filtered out of the gross time of the caller are added by default. In this way you can view the runtimes of objects
that you are interested in without the influence of programs and events that you have filtered out.
1.5 Tips and Tricks
Use
The runtime analysis tips and tricks contain a series of source code examples intended to illustrate efficient programming. For each problem, they present two
possible solutions, and you can compare their respective runtimes. The results enable you to see which solution is more efficient.
Note
To open the tips and tricks, on the initial screen, choose Tips & Tricks .
The system displays a list of measurable components, grouped by themes. When you choose an example the test screen appears.
Functions
The following functions are provided for the displayed examples:
Runtime measurement for the source code extract.
To use this function, choose Measure Runtime .
Displaying Data
To use this function, choose Global Variables .
Ability to modify the provided source code extracts
In both displays, you can directly type in, cut, copy, and paste.
Short documentation
The documentation is displayed at the bottom of the screen.
1.6 Measurable Components
Use
The runtime analysis does not measure all ABAP statements and operations, but only those that are potentially expensive in CPU time.
As you can see from the following table, the runtime components that are measured still allow you to trace the most important events during a program's execution.
Component Statement
Database Access All Open SQL statements
All Native SQL statements
EXPORT... TO
IMPORT... FROM
Modularization units MODULE
PERFORM
CALL FUNCTION including RFC calls
CALL SCREEN and processing blocks of the Dynpro flow logic, as well as data
preparation for Dynpros
CALL TRANSACTION
CALL DIALOG
CALL METHOD
SUBMIT
ABAP Objects statements CALL METHOD
CREATE OBJECT
RAISE EVENT
Internal table operations APPEND
COLLECT
SORT
INSERT
MODIFY
DELETE
READ TABLE
LOOP
Data Transfer READ DATASET
TRANSFER
Other statements ASSIGN
EXPORT
GENERATE
IMPORT
MESSAGE
SET LOCALE
SET PF-STATUS
SET TITLEBAR
PUBLIC
© 2014 SAP AG or an SAP affiliate company. All rights reserved.
Page 27 of 28
SET SCREEN
SUPPLY TO CONTEXT
DEMAND FROM CONTEXT
SCAN
CONVERT TEXT
Other Components System administration time
Load operations
Initialization
Program Generation (GENERATE)
PUBLIC
© 2014 SAP AG or an SAP affiliate company. All rights reserved.
Page 28 of 28