WebSphere Studio Application Developer Version 5 Programming Guide part 70 pdf

Using the performance analysis data gathered by the agent, you can identify potential problems by focusing on: ? Time consuming classes and methods ? Memory intensive classes and methods

Select the ItsoProGuideJava project, and enter itso.bank.main.BankMain as the main class

Figure 20-9 Launch Java Process

The remainder of the wizard is the same as the Attach to Java Process wizard

We leave the default options, so click Finish Your are automatically taken to the Profiling perspective, the Java process is launched and monitored, and the output is displayed in the Profiling Console view, as shown in Figure 20-10

Retrieve the data using Refresh Views You can now analyze the profiling data that was collected, as explained in “Performance analysis” on page 666

Figure 20-10 Profiling Console view

Profiling remote processes

The profiling feature in Application Developer allows you to monitor applications running on a remote host The only requirement is that the host has to have the IBM Agent Controller installed and running

If Application Developer is not installed on the remote host, the Agent Controller has to be installed separately IBM Agent Controller is available for many different environments, including AIX®, HP, Windows, zOS, i-series, Linux, and Solaris Attaching a Java process on a remote machine is done by creating a remote server and starting it in profiling mode Details about creating a remote server can be found in “Creating a remote server and file transfer mechanism” on page 520

Profiling a remote server uses the same process as a local one, as described in

“Profiling an application in the WebSphere Test Environment” on page 658

Performance analysis

Before we analyze the performance, we must simulate end user usage using a Web browser In this section we analyze the data collected by running the

ItsoProGuideBasicWeb application we EJB access As you use the Web application, the profiling agents collect data

Using the performance analysis data gathered by the agent, you can identify potential problems by focusing on:

򐂰 Time consuming classes and methods

򐂰 Memory intensive classes and methods

򐂰 Garbage collection statistics

򐂰 Objects that are not garbage collected

򐂰 Thread activity

To help you analyze the data returned by the profiler, Application Developer provides a number of different views that focus on different aspects of the data They include:

򐂰 Package statistics (statistical)

򐂰 Class method statistics (statistical)

򐂰 Method statistics (statistical)

򐂰 Heap (graphical)

򐂰 Execution flow (graphical)

򐂰 Object interactions (graphical)

򐂰 Class interactions (graphical) The different views should be used in conjunction to gather the complete picture

of your application performance This will provide you with the information required to determine where you can most productively concentrate your efforts

to improve performance

The views are linked together; that is, if you have selected something in one view, the other views will show information about the same object This makes it easy to collect all information about a particular object

As an example, if you select a class from the Package Statistics view, you can switch to the Class Method Statistics view to get details about the execution of the methods of that class

To update the information in the profiling views to show the latest data captured

by the profiler, select Refresh Views from the view menu This will refresh all the views, not just the one you are currently in

Package statistics

The Package Statistics view shows information about the packages in your application (Figure 20-11)

Figure 20-11 Package Statistics view

By default this view shows the following information about the packages:

򐂰 Total basetime for all classes in the package

򐂰 Total cumulativetime for all classes in the package

򐂰 Number of calls made to each class

򐂰 Number of live object instances of the class for which garbage collection has not occurred

򐂰 Active size of memory consumption by each live object instance of this type Base time of a method is the time spent executing this method only It does not

include time spent in other Java methods that this method calls

Cumulative time of a method is the time the method spends on the execution stack, including both time spent in the method itself and in other methods that it calls

In statistical profiling views, the following icons appear:

򐂰 Indicates that there is an increase in the numeric value for that particular cell in the table since the last time the view was refreshed

򐂰 Indicates that there is a decrease in the numeric value for that particular cell in the table since the last time the view was refreshed

򐂰 Indicates that the class, instance, or method is new since the last time the view was refreshed This icon shows up in the narrow second column

You can tailor the display by adding and deleting columns Select Choose Columns from the context menu (Figure 20-12). You can add or remove columns

from the view by selecting or deselecting them from the list

Figure 20-12 Choose columns dialog

You can sort on different columns by clicking in the column header If you are interested in determining the package with the longest base time, you would click

in the header of the Base Time column

Class method statistics

The Class Method Statistics view shows information about individual classes and their methods in your application This view goes into more detail about each class and method than Package Statistics view (Figure 20-13)

By default, this view shows the following information about your methods:

򐂰 Class names

򐂰 Method names (when the class name is expanded)

򐂰 Package to which each class belongs

򐂰 Total base time spent in each class, and broken down by method

򐂰 Average base time spent in each class, and broken down by method

򐂰 Total cumulative time spent in each class, and broken down by method

򐂰 Number of calls made to each class, and broken down by method

Figure 20-13 Class Method Statistics view

Method statistics

The Method Statistics view is essentially the same as the Class Methods Statistics view, except that it lists all methods together instead of separating them

by class This allows us to sort by base and cumulative times to compare all methods The view is shown in Figure 20-14

This view has the same columns as the Class Method Statistics view, except here the package column is replaced by a class name column

Figure 20-14 Method Statistics view

Heap

The Heap view is the most versatile profiling view and can be used to help you in

a number of performance analyzing tasks, such as:

򐂰 Identifying time-consuming objects and methods

򐂰 Identifying memory-intensive classes

򐂰 Gauging garbage collection

򐂰 Gauging program concurrency

򐂰 Identifying memory leaks

򐂰 Browsing method execution as a function of time

The Heap view is color coded to make it easier to identify trouble spots in the code (Figure 20-15)

Figure 20-15 Heap view

This version of the Heap view shows base time per class Red is used to indicate classes that have a relatively high base time To switch to other types of

information in this view, you select from the Color by drop-down combo box (Figure 20-16)

Figure 20-16 Heap view options

Each of the options will show a different perspective on the application performance You can switch between showing objects and showing methods by using the icons in the toolbar at the top of the view, ( and )

The status line at the bottom of the Heap view displays information about the currently selected object or method in the view

The following sections describe how you can use the Heap view to help you with the tasks listed above Note that the other profiling views can also be used for some of the tasks or to provide additional information

Identifying time consuming objects and methods

Select Cumulative Time in the Color by combo box As the default, the slider is positioned at the maximum value along the scale and you see mostly blue and black colored class instances

Move the slider, adjusting the color coding until you see a variation in the color of the rectangles that represent object instances, or diamonds that represent class objects in Objects mode; or the rectangles that represent the methods in Methods mode (Figure 20-17)

Figure 20-17 Heap view before and after adjusting the slider

Slider

Select the object or method instance that is a color other than blue or black Observe the status line, and note the instance of the object or method The status line also tells you the amount of base time that this instance consumed, as well as other statistics

The same process can be repeated for all entries in the Color by combo box

Gauging garbage collection

The objects for which garbage collection has occurred are represented by empty rectangles By positioning the mouse over such objects, you get information (in the status line) on the time at which garbage collection occurred for the object

Identifying memory leaks

The histogram that is displayed in the Heap view in Objects mode shows the garbage collection status of instances of objects The color-filled rectangles denote instances for which garbage collection has not occurred

Unexpectedly large numbers of such instances may suggest a memory leak Source code analysis can help you to investigate these objects, and find their creators, and any objects that refer to them

Browsing method execution as a function of time

Click to switch to Methods mode Instead of class instances, you now see the heading class methods in the right column Each square represents one method for the class on that line (Figure 20-18)

Select a method in the Heap view The status line displays the name of the method, the base time, the cumulative time, and the number of calls of that particular method This information gives you an indication of the time (in seconds) that was spent executing that method In our case, we select

PerformTransaction.doPost

Note: A class name might be red, but the rectangle representing it in the

histogram might be blue The reason for this difference is that there are many instances of the class, but each one alone does not occupy much memory (blue) However, the total combination of all such instances takes up a lot of memory (indicated by the red font color for the class and the length of the bar

in the histogram)