Viewing performance bottlenecks

Performance bottlenecks can be readily identified by using the statistical views. This topic describes a scenario in which we seek to improve execution time. The Package Statistics view is a good starting point because it identifies the packages responsible for slow execution time. From here, we drill down and look for the class or method responsible for the execution poor performance.

When launching the application to be profiled we enable the collection of execution flow information. (Select the profiling option, My application is too slow then, from the Details options, select Show Execution flow graphical details.)

The Package Statistics view, when opened, looked like this:

This view shows statistics of the different classes, grouped by their containing packages. The view can be customized to display any type of statistical data, such as memory allocation or time based statistics. In our case, we make sure the time related columns were visible because they contain the information we needed. (Right click, select Choose Columns, then set these columns to be visible.) We also sort the packages using the execution Base Time column. As you can see above, the com.ibm.ws.ejbpersistence.dataaccess package is the execution "hot spot" and, within this package, DataAccessRequestImpl is the class responsible for the slow execution time.

Once we get this information, we drill down to the Class Statistics view and identify the method responsible for the class's overall poor performance.

Now we can clearly see that the execute method is the one responsible for the poor performance of the DataAccessRequestImpl class; its execution time is very high compared to the time spent in the other method, executeOneRowFBPK.

Let's look closely at the Class Statistics view. There is one really interesting thing worth noticing while we are here: the java.text.NumberFormat class is next on the list of classes responsible for slow execution time. And, in particular, the java.text.NumberFormat.getCurrencyInstance() takes up the time spent in that class. This can give you an idea of what it costs to use some apparently simple methods. Even if NumberFormat.getCurrencyInstance() seems to be a simple API, calling it many times can have a big impact on your application's overall performance.

We now turn to the method invocations for the DataAccessRequestImpl.execute() method. One powerful feature of the profiling tool is the graphical representation of the application execution, which lets you can see the method execution at the method invocation level. This view is useful because you can see the execution pattern and the differences between invocations of the same method. Here is the Method Invocation view to illustrate the invocation of the DataAccessRequestImpl.execute() method.

From this graphic you can see either what called this invocation in the execution stack or you can jump to the source code of the method. You can also see the time spent by hover the cursor over any bar.

The Method Invocation table below displays the same method invocations, but in a tabular format. It's interesting to notice that for the first method invocation, the execution time (see the Cumulative Time column) is very high compared to later method invocations.

By analyzing the method invocations execution stack, we can find the reason why this specific invocation was slower than the rest of the method executions. Looking at the method invocations pattern, we find that the first call to the OnlineItembean.FindByValue(IndexedObject) method takes a lot more time than the rest of the method invocations.

So, finally, we found that the method responsible for the overall long execution time is the very first invocation of the OnlineItembean.FindByValue method.

Related concepts
Overview of the Profiling Tool