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