In my previous weblogs in this series - BSP Performance: Measuring Roundtrip Latency and BSP Performance: Statistic Records for Server Latency - we looked at techniques for measuring the actual performance of a BSP application. The next logical question is: can we improve that performance? That question can be answered only if we know what the application in question is doing.
For this last piece of the puzzle, we will use runtime analyses to get a detailed picture of an application’s runtime behaviour. (This weblog does not seek to analyze any specific application; rather, it explores the tools available and looks at expected output.)
Activating Runtime Analysis
The runtime analysis of a BSP application (of any HTTP request, actually) is activated in ICF (see transaction SICF). See also the online help.
After the runtime analyses have been enabled, execute a few test BSP pages.
Looking at the Data
The data collected by the runtime analyses can be seen using transaction SE30. Simply select “Other File…” for the specific user, then double-click on any of the URLs listed.
The gory details are not interesting in the context of this weblog. Instead, let us look briefly at the type of information that can be learned from transaction SE30. The true value of this tool can only be learned from practical (home:) work. Also read the documentation.
The first interesting aspect is the Hit List. This shows all methods and functions called, and their gross and net times. To get an overview of which methods have the longest runtimes, sort on the net times. Also shown is the number of times each method is called. This often helps identify inefficiencies in the way that code is structured.
The Group Hit-List shows top entries grouped into different categories, including method calls, function calls, database access, and program load times.
Database access is usually the more expensive part of an application, and the Database Hit-List provides detailed information about databases that were referenced.
The Call Hierarchy shows the true calling sequence of the application. This can be a daunting display for complex applications, but helps to correlate the dynamic behavior of the application to the more static code one sees in the editor. This is especially interesting to understand paths taken through the code, and for the “who called this method” type of question.
It is always possible to use forward navigation (double-clicking) to get more detailed information about any specific sequence that is displayed. Use the blue “Display Source Code” button at any point to jump directly to the relevant source code.
Summary
This weblog has added the “what is happening” tool to the performance toolbox. This is the most interesting one, as it allows us to find hotspots in the code, and to zoom in the specific areas that can be improved.