Skip to main content

J2EE application profiling in WebSphere Studio

Benedict Fernandes (bxf@us.ibm.com), Software Consultant, IBM
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 Manji (amanji@ca.ibm.com ), Software Developer , IBM, Toronto
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.

Summary:  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.

Date:  28 Oct 2003
Level:  Introductory
Activity:  1083 views

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.


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
ALT TEXT

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:

  1. 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.
  2. 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.
  3. Execution: During this stage, the agent monitoring is selectively enabled and disabled to facilitate collection of relevant performance data for the appropriate use cases.
  4. 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 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
ALT TEXT

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.


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:

  1. Select Window => Open Perspective => Other => Server.
  2. 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.
  3. 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.
  4. 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
    Server perspective -- Add project to server
  5. 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
    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
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
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
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
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
 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
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
J2EE perspective -- Running client tests

Selecting Experiment #1 will bring up the page as shown below:


Figure 13. J2EE perspective -- Experiment 1
2EE 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
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
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
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
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
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
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

NameSizeDownload method
ProfilerExpts.zip14KBFTP|HTTP

Information about download methods


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.

Comments (Undergoing maintenance)



Trademarks  |  My developerWorks terms and conditions

Help: Update or add to My dW interests

What's this?

This little timesaver lets you update your My developerWorks profile with just one click! The general subject of this content (AIX and UNIX, Information Management, Lotus, Rational, Tivoli, WebSphere, Java, Linux, Open source, SOA and Web services, Web development, or XML) will be added to the interests section of your profile, if it's not there already. You only need to be logged in to My developerWorks.

And what's the point of adding your interests to your profile? That's how you find other users with the same interests as yours, and see what they're reading and contributing to the community. Your interests also help us recommend relevant developerWorks content to you.

View your My developerWorks profile

Return from help

Help: Remove from My dW interests

What's this?

Removing this interest does not alter your profile, but rather removes this piece of content from a list of all content for which you've indicated interest. In a future enhancement to My developerWorks, you'll be able to see a record of that content.

View your My developerWorks profile

Return from help

static.content.url=http://www.ibm.com/developerworks/js/artrating/
SITE_ID=1
Zone=WebSphere
ArticleID=13705
ArticleTitle=J2EE application profiling in WebSphere Studio
publish-date=10282003
author1-email=bxf@us.ibm.com
author1-email-cc=
author2-email=amanji@ca.ibm.com
author2-email-cc=

My developerWorks community

Tags

Help
Use the search field to find all types of content in My developerWorks with that tag.

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).

Use the search field to find all types of content in My developerWorks with that tag. 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).

Rate a product. Write a review.

Special offers