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.
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
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 article 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 Updates.
Setting 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.
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
ProfileServerfor Server name andServersfor 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
ProfileExptsproject to theProfilerServerinstance.
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
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
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
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
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.
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.
| Name | Size | Download method |
|---|---|---|
| ProfilerExpts.zip | 14KB | FTP |HTTP |
Information about download methods
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.
Comments (Undergoing maintenance)
Table of contents
Next steps from IBM
Rational Application Developer features provide the comprehensive Integrated Development Environment (IDE) used to develop J2EE applications requiring Servlets and JavaServer Pages (JSPs).
- Try: Try the free Rational Application Developer, which helps developers quickly design, develop, test, analyze, and deploy high-quality Java, Javaserver pages, and J2EE applications.
- Article: Learn how you can deliver accurate, higher-quality J2EE apps with Rational Application Developer, open source JUnit and JUnitEE test frameworks.
- Tutorial: Build a Facebook application using PHP, the Spring framework, and J2EE.
- Buy: Rational Application Developer
My developerWorks community
Tags
Use the slider bar to see more or fewer tags.
Popular tags shows the top tags for this particular content zone (for example, Java technology, Linux, WebSphere).
My tags shows your tags for this particular content zone (for example, Java technology, Linux, WebSphere).
Popular article tags |
My article tagsSkip to tags list
Popular article tags |
My article tags
