Application Development Blog Posts
Learn and share on deeper, cross technology development topics such as integration and connectivity, automation, cloud extensibility, developing at scale, and security.
cancel
Showing results for 
Search instead for 
Did you mean: 
OlgaDolinskaja
Product and Topic Expert
Product and Topic Expert
SAT is the transaction name of the new ABAP Runtime Analysis Tool, which is one of the most significant improvements in ABAP in the NetWeaver 7.0 EhP2. For those of you who are already familiar with the transaction SE30, the former ABAP Runtime Analysis Tool, transaction SAT is the successor of SE30. In SAT, ABAP's Runtime Analysis has been reworked by SAP's R&D department and has been enhanced with effective new analysis tools and features. 

SAT offers benefits such as a modern state-of-the art UI, new analysis tools, easy navigation between tools and so on.  As successor of the transaction SE30 SAT should be used for performance measurements. If you use SE30, you would be pleased to know, that the SE30 functionality for performance analysis is still the same in SAT and was just enhanced by new performance analysis tools.

The second blog of these series of blogs about SAT devotes itself to the analysis of performance problems and demonstrates how the new tools and features of the SAT help you efficiently to analyze the performance of any ABAP application.

These series of blogs about SAT are suitable both for newbies and for experienced SE30 users. You can find other blogs from these series about SAT here:

 

Next Generation ABAP Runtime  Analysis (SAT) – Introduction

Next Generation ABAP Runtime Analysis (SAT) – How to analyze memory consumption

Next Generation ABAP Runtime Analysis (SAT) – How to analyze program flow

 

If you want to see a live demonstration of SAT, take a look at this short video:


1. How to analyze performance problems


 

Just imagine the following situation. Your ABAP program is running and running and running and you ask yourself: why does this short ABAP program need so much execution time? To find the answer, some of you maybe would turn on the SQL trace to check if any SELECT's on the database are slow or even try to debug it.  These checks could cost you a lot of time. But actually the ABAP Runtime Analysis is the best starting point for any performance analysis. Here you can quickly get information about the cause of a performance problem: if it is an ABAP or a database problem, does it relate to your component or not and so on.

 

Now it's time to explain, how to execute and analyze performance measurements with SAT. Let's take the following scenario as an example. Imagine you are in the ABAP Workbench (SE80 transaction), you try to expand all of the nodes of the BASIS package, and you see that it takes some time. Let's analyze the performance of this operation with SAT.

 

First you must start the ABAP Runtime Analysis (SAT) and create a measurement variant.

 

1. Start the ABAP Runtime Analysis (SAT) via System -> Utilities -> Runtime Analysis -> Execute or call the transaction "/nsat" directly.

2. Type "SE80" into Transaction field

3. Choose Eval. Immediately to start the analysis right after the measurement

4. Choose Determine names of internal tables to see the source-code names of internal tables in the measurement

5. Create your own measurement variant:

  • Type a name into Variant field and press Create button

  • Choose aggregation Per Call Position on the Duration and Type tab

  • On the Statements tab choose additionally to default options operations on Internal Tables

  • Save your variant


6. Press Execute button to start the measurement.

 



 

In the ABAP Workbench (SE80) choose BASIS package. Open the package by choosing Expand all nodes button, and then collapse the the tree of objects again with the Collapse all nodes button. Finally, return to SAT by pressing the green arrow Back button.

 

For aggregated measurements SAT displays the most relevant evaluation tools on Desktop 1. These are the Profile Tool and Hit List Tool.

Let's take a look at measurement results in the Profile Tool. The Profile Tool gives a broad overview of how the runtimes of the application are distributed. At first look the display appears fairly technical: it is the display after the trace run. Fortunately, however, on the left there is the Other Hierarchy" button that lets you group runtimes by components that you are interested in, by packages and so on.

 

Let's evaluate our performance measurement results.

 

1. Use Other Hierarchy button to choose the Components view

2. Position the cursor on the "BC" component that has the highest runtime consumption

3. Press the right mouse button and choose Expand: Packages in the context menu to expand packages of the "BC" component

4. Expand the entry of the "BASIS" package. Here you can see that the largest portion of the runtime was used up in both of these packages: "SOLE" and "SEU". We will take a look at both of them.

 



 

5. Position the cursor on the "SOLE" package and use the right mouse button to expand its trace results (Expand: Trace Results). Here you can see at the top the trace the event "Wait for RFC", which tells you that here our application spent runtime in waiting for an RFC call to complete. You can display the RFC call in the Hit List via double clicking. You can then jump directly to the source code (again double click on the trace event in the Hit List).

6. Position the cursor on the "SEU" package and use the right mouse button to expand its programs (Expand: Programs). Open the node of Function Groups and expand trace results of "SEWB_CONTROL"(Expand: Trace Results). Take a look at the tables and see that the majority of the runtime falls on a "LOOP AT".

7. Position the cursor on "LOOP AT" and choose Display Subarea in Hit List Tool. The Hit List displays trace events sorted according to net runtime. You see also the names of internal tables in the measurement result.

8. Click on the top performance consumer and take a look at the source code. You'll find a nested loop over the table "l_objectlist" and it, a construction that can be expensive in terms of runtime.

 

As you can see, with just a few clicks in the Profile Tool and Hit List Tool we were able to localize a couple of critical performance hotspots that account for much of the runtime in the operation of  expanding the nodes of a package in the ABAP Workbench (SE80).

 

Best Practices for a Performance Measurement


 

When you measure the performance of your ABAP application remember the following:

  • Use aggregation Per Call Position in a measurement variant to create traces for evaluating performance in the Profile Tool and Hit List Tools.




  • Use the Profile Tool in combination with the Hit List Tool to look for performance bottlenecks.

  • Start analysis in the Profile Tool by using Component view. If you have no idea about the source code location of the performance consumer, you can drill down in the trace display from the Component view to single trace events by following on the top performance consumers.

  • In most use cases you are interested in net runtimes. The net runtime is the gross runtime of the method minus all other events called by this method.

  • If your application consumes disproportionately more runtime with a larger amount of data, compare Hit Lists of both performance measurements to check for scalability. You can access the Hit List comparison Tool on the Evaluate tab of the SAT initial screen by selecting two compatible measurements and pressing Compare Hit Lists button.

  • For more detailed performance results use the Times Tool and the Database Tool.


 

 


2. How to restrict a performance measurement


 


Now imagine the following situation. You have a long running process and need to analyze its performance. If you simply start a performance measurement for such process your trace file quota could be exceeded before you have traced the part of the process you are interested in. Therefore it is generally recommended to reduce the size of performance measurements, especially performance measurements of long running programs.

 

The size reduction strategy is to execute a performance measurement at first only for particular statements (functions, forms, methods, etc.) to look for top consumers. Then, you can restrict the measurement in a second run to the modules that are killing performance, which you detected as hot spots during the first run. Additionally we recommend measuring only the relevant part of your ABAP application by switching the trace on and off interactively, so that you trace only the critical sections.

 

Let's take a look at how you can control the size of a performance measurement with SAT. Just imagine you are in the ABAP Editor (transaction SE38) and notice that the execution of your report takes a long time. We will analyze the performance of this report with SAT.

 

First you must start the ABAP Runtime Analysis (SAT) and create a measurement variant.´

 

1. Start the ABAP Runtime Analysis (SAT) via System -> Utilities -> Runtime Analysis -> Execute or call directly the transaction "/nsat".

2. Type a name of the report into Program field

3. Choose Eval. Immediately to start the analysis right after the measurement

4. Create your own measurement variant:

  • Type a name into Variant field and press Create button

  • Choose aggregation Per Call Position on the Duration and Type tab

  • On the Statements tab choose only all Processing Blocks

  • Save your variant


5. Press Execute button to start the measurement.

 



 

After the measurement has been created, SAT displays the measurement results. If you take a look at them in the Hit List Tool and sort them by net runtime, you will see that it is the TEST2 method call of the LCL_TEST class that consumes the most runtime of the report:

 



 

Now it is time to restrict the performance measurement to the top performance consumer. Just go back to SAT initial screen and restrict the variant to the method TEST2 of the LCL_TEST class, but now setting the variant to measure all statements.

Press the Change button for your measurement variant:

  • Select all statements on the Statements tab

  • Choose Limitation on Program Components on the Program Components tab

  • Choose Measure functions called by specified program parts on the Program Components tab and enter the method TEST2 of the LCL_TEST local class of your report


 



 

Now measure the performance of the report again. The Hit List now shows where exactly this report has lost performance.

 



 

And if you double click on the topmost trace event to jump into the source code, you will see that the problem is the read on the internal table. Obviously, the read does not use any key fields and therefore executes a very "expensive" full table scan each time that it is executed. By the way, in NetWeaver 7.0 EhP2 you can create a secondary index on ABAP internal tables (you probably know secondary indexes from database tables). In this case you would create a secondary index which would cover the columns "c" and "d" of the internal table ITAB in order to optimize the performance of the TEST2 method.

 
Best Practices for a Performance Measurement Restriction

 

When you measure the performance of your ABAP application remember the following:

  • Restrict the trace measurement by explicitly naming the statements to trace. You can explicitly name statements you are interested in on the Program Components tab of your variant.

  • Trace only relevant parts of your ABAP application. Use Explicit Switching on and Off of Measurement option in your variant where possible and then turn on/off the trace with "/ron" and "/roff" commands.




  • Restrict the measurement in a first run to processing blocks. Focus the trace in the following runs on the major performance killers. You can restrict the ABAP statements in the measurement on the Statements tab of your variant.

17 Comments