Level: Introductory Benedict Fernandes (bxf@us.ibm.com), Software Consultant, IBM
Ali Manji (mailto:amanji@ca.ibm.com), Software Developer , IBM, Toronto
28 Oct 2003 This article explains the concepts behind the WebSphere Studio Profiler and shows you step-by-step how to configure it and use it to monitor the performance of a sample application. Introduction IBM ® WebSphere® Studio Application Developer V5.0.1 (hereafter called Application Developer)
gives you the ability to profile Java applications. Profiling gives you insight into the performance characteristics of your application.
Knowing more about your application's run-time behavior promotes a better understanding of its resource requirements and potential
bottlenecks. This knowledge can help guide your design, implementation, and update decisions throughout the project lifecycle. This article shows you how to install, configure, and use the Application Developer Profiler. It will illustrate
the steps required to profile a simple application, and briefly discuss the high-level architecture used by the Profiler.
This article will not discuss techniques or best practices to optimize algorithms or data structures for performance. There are many
resources on this topic, a few of which are listed in Related content.
Profiler architecture You can use the Application Developer Profiler to gather information on a standalone Java application
or an application running within a J2EE-based application server such as WebSphere. In both cases, profiling can be done either locally
or remotely relative to the application's target host. Furthermore, profiling can occur across multiple Java Virtual Machines (JVMs). The Profiling perspective in WebSphere Studio gives you a collection of views with both graphical and tabular
representations of a Java program's run time. Several interacting elements form the major components of the profiling architecture:
Figure 1. Profiling architecture
A key component of the architecture is the IBM Agent Controller, which is installed on the deployment host.
The Agent Controller comes with two agents with which it can interact: the piAgent and the J2EE Request Profiler agent.
These agents are responsible for collecting any performance-related information. The agents run directly inside the JVM and are based on
the Java Virtual Machine Profiler Interface (JVMPI) architecture.
The agents collect performance data and forward it to the Agent Controller, which passes the collected data to the Profiler tool
in Application Developer where the information is displayed. The Application Developer Profiler provides an interface that passes control information to the Agent Controller, which
in turn passes it to any actively monitoring agents. The control information is used, for example, to filter out unwanted information. The J2EE Request Profiler agent resides within the application server JVM. It collects data by intercepting requests
coming in to any EJB and Web containers present. You can view the collected data via a set of sequence diagrams within the Profiling
perspective. The J2EE Request Profiler agent lets profiling span host and JVM boundaries. Features of the J2EE Request Profiler agent
will be discussed in a future article.
WebSphere Studio profiling methodology The process of profiling an application using Application Developer can be divided into four stages:
Install
The important tasks during this stage are to ensure that the correct version of the Agent Controller is installed and running
on the deployment hosts. In most situations, the J2EE application to be profiled will require access to JDBC and JMS resources.
In these cases, you must create and configure a WebSphere Test Environment (WTE) server instance.
Setup
In this stage, the key step involves starting the WTE server that we created and configured in the previous stage in profiling mode.
In addition, you specify the various profiling control options to specify the kind of data that the agents collect.
Execution
During this stage, the agent monitoring is selectively enabled and disabled to facilitate collection
of relevant performance data for the appropriate use cases.
Analysis
This stage uses several statistical and graphical viewers provided by the Profiler to interpret and analyze the performance data
collected during the execution stage. Analysis of performance bottlenecks can help you tune the application code or application
resources, and these changes will need to be further profiled and analyzed for to verify improvement.
Figure 2 presents a flowchart of the methodology:
Figure 2. Profiling methodology
Install/update phase Software prerequisites Profiling requires the correct version of the IBM Agent Controller to be installed and running on the host
where the profiled JVM is running. To verify whether the IBM Agent Controller is installed and running, follow these steps: Start => Settings => Control Panel => Administrative Tools => Services Figure 3 displays the IBM Agent Controller service that is running.
Figure 3. Agent Controller
If the IBM Agent Controller is not running, start the service. If the most recent version of the Agent Controller
is not installed, download and install it from: This paper is based on Application Developer V5.0.1. There are several differences between this version of the Profiler
and previous versions. The versatile Heap View is no longer available, and the user-interface has also changed in some places.
To verify that you have the latest version of Application Developer, start the product and select
Help => About IBM WebSphere Studio Application Developer. Help => Software Updates => New UpdatesSetting up the sample application In a typical profiling situation, the application to be profiled has been developed and tested within
Application Developer. In some cases, an existing application might be imported into Application Developer to be tested and profiled.
For the purposes of this article, a sample J2EE Web Application with JSPs and Java classes is provided.
You can download the sample application at the bottom of the article.
Save the ProfilerExpts.ear to your C:\temp directory and then select File => Import => EAR File.
In the Import dialog box, enter C:\temp\ProfilerExpts.ear in the EAR file field and enter ProfileExpts.
in the Project name field. Finally, click Finish.
Setup phase Setting up the WebSphere Test Environment Before we start profiling, you must create and configure an instance of the WebSphere Test Environment (WTE) server.
Typically, the required J2EE application resources such as JDBC, JMS, JAAS, and so forth are configured during this step.
To create WTE server instance, follow these steps:
- Select Window => Open Perspective => Other => Server.
- In the Server Configuration view within the Sever perspective use the context menu and select Servers => New =>
Server and Server Configuration to create a new WTE server instance.
- In the Create a New Server and Server Configuration dialog box that follows,
enter
ProfileServer for Server name and Servers for Folder, and
select WebSphere Version 5.0 => Test Environment for Server type. Finally, click Finish.
- Associate a project with the ProfilerServer. As shown in Figure 4, add the
ProfileExpts project to the
ProfilerServer instance.
Figure 4. Server perspective -- Add project to server.
- Start the server in profiling mode. From within the Servers view of the Server perspective,
select the ProfilerServer and select the Profile menu option from the context menu as shown in Figure 5.
Figure 5. Start server in profiling mode
Configuring profiling options Starting the ProfilerServer causes the respective embedded Profiling agents to be displayed.
Select the options as indicated in Figure 6 to select the agents that you want to monitor. The Process ID (PID) values indicated here
correspond to the Application Server V5.0 PID allocated by the operating system at server startup.
Figure 6. Attach to profiling agents
Click Next to continue the profiler configuration process. In the next dialog box in the series, you can optionally specify a Profiling Project and Monitor.
In this case, keep the defaults and select Next. To collect relevant performance data, exclude all the system and infrastructure level packages
and include application-specific packages only. To simplify this procedure, three predefined filter sets are provided, with the
WebSphere J2EE filter set the most comprehensive one. Select the WebSphere J2EE box, as shown below:
Figure 7. Specify profiling filters.
Selecting the WebSphere J2EE filter set prevents the agents from collecting data pertaining to the standard
J2EE packages. On the other hand, we want to collect performance data that is relevant to the application that we are profiling.
To do this, add a filter to include the acme.* packages. Click Add (circled above) and
enter the values as shown in the Add filter dialog box. Click OK, then select Next to continue. Some data from packages that you would expect to be filtered out will spuriously appear in the profiling views.
This is a known problem. Various profiling options, as shown in Figure 8, let you further specify the level of detail for which
performance data can be collected by the profiling agents. Select the appropriate options and click Next to continue.
Figure 8. Specify profiling options
The Profiler configuration is now complete. Click Finish. Successful completion of the Profiler configuration process launches the Profiling perspective, as shown below.
The configured profiling agents are displayed in the Profiling Monitor view. Click OK to continue.
Figure 9. Profiler setup completion
Execution phase Any collected performance data can be viewed via several graphical and statistical viewers. Right-cick on
the profiling agent as shown below and open each of the following views: Package Statistics, Class Statistics,
Method Statistic, and Object Reference.
Figure 10. Profiling perspective -- Profiler views
Starting monitoring Before running any specific test cases, you need to enable monitoring on the profiling agent; otherwise data collection
will not occur. To enable monitoring, switch to the Profiling perspective. In the Profiling Monitor view, right-cick on the Profiling agent
and select Start Monitoring:
Figure 11. Profiling perspective -- Start monitoring
Exercising profiling test cases With the server running in profiling mode, you are now ready to profile the examples.
The entry page for the application is the profiling.html page. From the J2EE perspective -- Navigator View,
select the profiling.html page and then select Profile on Server. The page shown in Figure 12 below will open in the internal Web browser. The page provides two experiments
that can be profiled. From the internal Web browser, select the specific profiling test experiment URL once and wait
until the results page is displayed.
Figure 12. J2EE perspective -- Running client tests
Selecting Experiment #1 will bring up the page as shown below:
Figure 13. J2EE perspective -- Experiment 1
Experiment 1 is a simple application that serializes instances of an Employee class to a file.
Serialization of classes is a fundamental activity in most distributed applications. In this first experiment, all of the members
of the Employee class will be serialized. However, as you will see in Experiment 2, some members of the Employee class,
deemed non-essential for serialization purposes are marked transient and are not subject to serialization.
Therefore, the Employee class in Experiment 2 will require less effort to serialize, and Experiment 2 should have significantly better
performance. However, before running Experiment 2, switch back to the Profiling perspective to
further explore the performance characteristics of Experiment 1. The performance data is automatically collected but not displayed. Select Refresh Views to have the
profiler populate the views with the latest data:
Figure 14. Profiling perspective -- Refresh views
Figure 15 below illustrates the Package Statistics view in the Profiling perspective.
This view gives you wide insight into which packages in the application require the most object instances and memory. As mentioned,
some system-level packages that were supposed to be filtered out appear in this view.
In our example, the package acme.business.domain package is the most resource intensive:
Figure 15. Profiling perspective -- Package Statistics view
Figure 16 below shows the Class Statistics view in the Profiling perspective. This view shows
which classes in the application require the most object instances and memory. In the view below, the classes Project
and NotTransientEmployee require the most instances and memory, as shown by the fields Total Instances and Total Size.
The Collected field indicates how many of the total instances have been garbage collected and thus how much memory has been reclaimed.
Therefore, the Active Size field shows how much memory the class currently occupies with garbage collected instances taken into consideration.
In our example for Experiment 1, we can see in Figure 16 that the NonTransientEmployee and Project classes
require the most memory and most total instances, none of which appear to have been garbage collected.
Figure 16. Profiling perspective -- Class Statistics view
Figure 17 below shows the Method Statistics view in the Profiling perspective.
This view shows which methods require the most time to execute. It also indicates how many times a method is invoked. The Base Time field
indicates how much time was spent running a method, not including time the method spent calling and running other methods.
The Cumulative Time field indicates how much total time was spent to execute a method, including time spent invoking and running other methods.
The Calls field indicates how many times a particular method was invoked. The Average Base Time field is equal to the value
in the Base Time field divided by the value in the Call field. In our example for Experiment 1, we can see in Figure 17 below that the
writeNonTransientEmployees() method overwhelmingly requires the most time to execute, despite being invoked only once
in this application. Furthermore, all of the time was spent within this method and not in calling other methods.
Figure 17. Profiling perspective -- Method Statistics view
Figure 18 below shows the Object References Table view in the Profiling perspective, which indicates
the number of references a class makes to other classes. In Figure 18 below, the Number of References field is not populated.
This is a known problem with the Profiler.
Figure 18. Profiling perspective -- Object References Table view
Now that you have been introduced to the key Profiling views, close the Profiling perspective and stop the
WebSphere Test Server ProfileServer. Start ProfileServer again in Profiling mode.
Select the profiling.html page and then select Profile on Server again. Try profiling Experiment 2. Figure 19 below shows
the results of Experiment 2 in the internal Web browser. Open the Profiling perspective again and open the profiling views discussed above.
The results in many cases should convince you that Experiment 2 offers better performance both in memory and execution time.
Figure 19. J2EE perspective -- Experiment 2
Conclusion This article has discussed the architectural components used by the WebSphere Studio Profiler and showed you
how to install, configure, and use the Profiler to better understand the run-time behavior of an application. The article also discussed
how the performance data could be rendered and interpreted in a variety of views provided by the Profiling perspective of WebSphere Studio.
Future articles will describe how to profile a remote application running on WebSphere Application Server and how to use
the J2EE Request Profiler.
Acknowledgements The authors wish to thank Stacy Joines and Wilfred C. Jamison for reviewing this article.
The authors would also like to thank Harm Sluiman, Valentina Birsan, and Richard Duggan for answering our many technical questions.
Download | Name | Size | Download method |
|---|
| ProfilerExpts.zip | 14KB | FTP |HTTP |
About the authors | | |
Benedict Fernandes
is a consultant with IBM Software Services for WebSphere, based in Raleigh, NC. Benedict has been working with middleware technologies and distributed systems for over 10 years. He holds a MS in Computer Science from De La Salle University and an MS in Information Networking from Carnegie Mellon University. You can reach Benedict at
bxf@us.ibm.com
.
|
| | |
Ali Murtaza Manji
is a software developer at the IBM Toronto Lab and works with the WebSphere Studio Application Developer Service Team. You can reach Ali at
amanji@ca.ibm.com
|
Rate this page
| 
