Next Generation ABAP Runtime Analysis (SAT) - Introduction

You might also like

Download as docx, pdf, or txt
Download as docx, pdf, or txt
You are on page 1of 11

Next Generation ABAP Runtime 

Analysis (SAT) – Introduction


Posted by Olga Dolinskaja in ABAP Testing and Troubleshooting on 18-Jan-2011 01:44:42

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. This first blog of the series about SAT gives overview
of the most useful SAT improvements (particularly in comparison with the former SE30)
and gives a quick guideline how to use new features and tools of the SAT to execute
effective runtime analysis 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) - How to analyze performance

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:

SAT - Next Generation ABAP Runtime Analysis (Flash)

1. Getting started

Starting a trace measurement in SAT is quite similar to SE30. There are no major changes on the
initial screen from SE30 to SAT. A new tab Evaluate has been added to the screen. On the
Evaluate tab you can take a look at trace measurements results with their status, date of creation,
total runtimes and so on. By default your traces are shown, but you can change this by right-
clicking on the column Trace user and choosing the Set Filter.
In the old SE30, internal tables were identified only by their internal names (IT_<nn>). You will be
pleased to discover, that SAT can determine and show the real names of internal tables for the
trace measurement results.

One of the benefits of SAT is a new storage system for traces.  SAT stores traces in the
database. That means that you can display a trace from any application server in the system (in
SE30 only traces of the current application server are visible). You can also keep traces for a
longer time (in SE30 traces older than one week are deleted to save file system space). When
you display a trace measurement result the first time (e.g. by you double clicking it on the
Evaluate tab), it gets formatted and written to the database.

The switch to SAT from SE30 is simple: you can still use trace files that you created with SE30.
The old trace files are moved to the database just like new SAT traces. Keep in mind, the files will
be deleted on the file system and therefore they are not available in SE30 anymore.

2. Variants - The Basis of All Measurements

The variants are the basis of all measurements in SAT. You maintain trace conditions and
restrictions in a variant.

Before you start a measurement just press New button in the Settings area on the SAT initial
screen to create a new variant. You will see the screen with three tabs, which you already know
from the SE30: Duration and type, Statements, Program Components.
Use variants to get the trace data you need while keeping extraneous data and storage use to a
minimum. Especially for long running trace measurements it makes sense to restrict your trace
measurement as much as possible in order to not run out of limits of your trace file size.

Here are some practical tips for using variants most efficiently to restrict a trace:

 If you run a trace for performance measurement use Per Call Position aggregation to get
one trace entry for all similar calls. If for example the same method gets called 10 times, only one
entry will be created in the trace file, which would contain 10 as number of the hits and the sum of
the runtimes of the hits. Without aggregation 10 entries with runtimes will be written into trace file,
which results in a larger trace file. Note: if you run a trace to follow the program flow of your
application, use "None" aggregation to get a call hierarchy in a trace.

 Use Explicit Switching on and Of of Measurement option to switch on/off the trace only
where you need it, for example if you are interested in a special part of a transaction (between
screen 3 and 4). This option allows you to switch on/off the trace during the running ABAP
program. You also must activate Limitation on Program Components on the Program
Components tab. The trace will be started as soon as you enter "/ron" (trace on) in the OK code
field in your transaction. With "/roff " (trace off) the trace is stopped. Alternatively you can also use
the menu path: System -> Utilities -> Runtime Analysis -> Switch On / Switch Off.

 Don't trace "everything"- restrict the statements. Remember that about 40% of all trace
records belong to the operations on internal tables! Therefore they extremely increase the size of
a trace file. You can trace for example only Processing Blocks in a first run to find out the relevant
parts of code, and then trace most (or even all) statements of the Statements tab and specify
your found relevant code (programs, classes, function groups...) on the Program Components
tab.

 Explicitly name your programs/classes/functions...on the Program Components  tab if you


know beforehand which parts of the code you want to trace. You can even specify which sub
elements (like a subroutine, function of a function group, a method of a class...) shall be traced.

3. Running a trace measurement

After you created your trace measurement variant, you can run the trace. Enter a name of your
transaction (or program, or function module) into corresponding input field of the In Dialog area
on the initial screen and press Execute button.

If you used Explicit Switching on and Of of Measurement option in your variant to switch on/off
the trace only where you really need it, you have to activate the trace after your ABAP program is
running. Enter "/ron" (trace on) command in the OK code field in your transaction. Alternatively
you can also use the menu path: System -> Utilities -> Runtime Analysis -> Switch On.
Your trace is running now. You can stop the trace and return to SAT by pressing the green arrow
Back button. Alternatively you can enter "/roff" (trace off) command in the OK code field in your
transaction or use the menu path: System -> Utilities -> Runtime Analysis -> Switch Off.

4. Using trace evaluation tools

After your trace measurement was executed, it's time to analyze the trace results. Go to the
Evaluate tab on the initial screen, find your trace result and double click it. SAT also displays
trace results immediately after trace execution if you checked the Eval. Immediately checkbox on
the initial screen.

The display of the SAT is visually close to the new ABAP debugger. The user interface consists
of the desktops. You can set up each desktop as you wish, with up to four trace evaluation tools.
By default the Desktop 1 presents tools for analyzing performance and Desktop 2 tools for
analyzing program flow.
The old SE30 transaction offered only two main tools, the Hit List and the Call Hierarchy. SAT
offers a rich set of new tools to analyze different aspects of a trace:

 Hit List Tool works the same way as in SE30. It displays a hit list of all measured statements.
Identical events are summarized into one trace line together with their execution times. But
identical events from different calling positions of source code appear as different entries in the
hit list.
 Call Hierarchy Tool works the same way as in SE30. It displays operations and events as they
occur in a program.
 Profile Tool shows you the runtime distribution of components, packages, programs and even
debugger layers.
 Processing Blocks Tool displays a tree of processing blocks to get aggregated view on the call
sequence
 Call Stack displays call stack for each item of the Call Hierarchy
 Database Tables Tool identifies time-consuming database statements
 Times Tool displays more specific time measurement values for the single events of the call
hierarchy.

Here is what each tool looks like. Don't  worry - the information on using each tool follows!
Here are some guidelines when to use each tool.

 To measure performance, use the Profile Tool in combination with the Hit List Tool. The
benefit of the Profile Tool is that you can start a trace evaluation at your application component
(e.g. FI or HR) and drill down the trace results view through the sub-components and their
packages to follow up on the top performance consumers. Afterwards you can display the
subarea of a detected performance consumer in the Hit List Tool to analyze its trace events. It
saves your time and you get a short and transparent Hit List which is easier to understand.If you
want to see how it works, take a look at this blog Next Generation ABAP Runtime Analysis
(SAT) - How to analyze performance

 To analyze program flow, use the Call Hierarchy Tool in combination with the Call Stack
and Processing Blocks Tools. You can use Call Hierarchy to display trace events the way they
were called by the program. Since the display of the Call Hierarchy is a little large, you can
display a Call Stack for a chosen event of the Call Hierarchy or just choose the event and position
its display in the Processing Blocks Tool. There you will see all processing blocks (methods,
functions, etc.) you configured in your trace measurement variant and can better follow the call
hierarchy of the trace event and even display the critical processing blocks in terms of consumed
runtime or memory.If you want to see how it works, take a look at this blog Next Generation
ABAP Runtime Analysis (SAT) - How to analyze program flow

 To display detailed information on runtimes in the Call Hierarchy, use the Times Tool. For
example Times Tool shows a distribution of runtimes across non-system and system programs.

 
 Identify time-consuming database operations and accesses to buffered tables with the
Database Tables Tool. By using easy navigation of SAT you can display the subarea in the
detailed Hit List Tool to follow the runtime distribution of database accesses, or position in the
Call Hierarchy (and e.g. display a Call Stack) to follow the callers of the database access.

4. Working with user interface

Here are some guidelines for efficient work with the SAT toolset and user interface.

 Display more details on a specific entry by using Display subarea in... buttons. In some
tools you can navigate from the overall view to the details of the specific entry. Use the Overall
view (funnel button) to get back to the overall view.

 Navigate comfortably between tools by choosing Position in the... buttons. Working with
multiple trace evaluation tools requires easy navigation between them. By setting the cursor on
the trace entry in one tool and using Position in the... command of the right-mouse button menu
you can easily take a look at this entry in another tool. For example switch from the Hit List to the
Call Hierarchy.

 Focus on a specific sub hierarchy by using Confine to Subarea button. This command
confines the data in all tools to the statements that lie in the sub hierarchy of the selected node.
And some more common user interface features in the tools:

 Use Additional information button to show more fields in the tool display. You can choose
for example to display a package, a software component or a person responsible.
 Use Display Call Stack button to show the call stack for a selected entry. This feature is
available only within Call Hierarchy.
 Toggle between absolute and percentage runtimes by using "Absolute/Percentage Times"
button. If you choose this button, SAT toggles between displaying the runtimes as an absolute
value or as a percentage of the total runtime.

5. Comparing traces

In SAT you can compare two compatible traces. You can use the comparison tools to analyze in
detail the behavior of the application you are measuring. SAT offers two trace comparison tools:
Hit List Comparison and Call Hierarchy Comparison.

To start the trace comparison just mark two compatible traces on the Evaluate tab and press
Compare measurements button.  You can not only compare the traces of different application
servers of the system, but also the traces of completely different systems. This could be useful if
for example a program behaves differently in development and production systems, and you
need to find out the reason.  Just select one of the comparison traces on the Evaluate tab and
send it to another system via RFC call by clicking Send Measurement via RFC button.
Alternatively you can download a trace to a file and upload it on the target system.
Here are some guidelines for using trace comparisons effectively.

 To check your application for scalability, use the Hit List Comparison. Trace your program
twice, the first time with a smaller amount of test data and the second time with a larger amount
of test data. Then compare the traces. You can take a look at the ratio of the net times of events
in both traces. If you know the factor by which you have multiplied the amount of test data in the
second measurement, you can examine the results and check if the net time ratios are greater
than the factor.

 To check the effect of changes to your code, use the Hit List Comparison. You have
optimized a critical portion of your code? You can check that the improvements work as you
expect with the Hit List Comparison. Trace the old code and then the new code using the same
set of test data. Then check for changes in the runtime in the trace comparison.

 To identify branches in the program that were not executed in a previous program
execution use Call Hierarchy Comparison. This could happen if for example the program
sources have changed since the last measurement, or if you use different starting parameters or
different custom data and so on.

This is basically everything you need to know about SAT before starting work with it. For more
information on special usage scenarios of SAT like performance analysis, program flow analysis
or memory consumption analysis read specialized blogs of these SAT series mentioned in the
beginning of this blog.
There is also a detailed application support (F1 help) for using SAT and its tools integrated in the
SAT transaction. Just take a look at it at your leisure.

You might also like