Published January 2006

Introduction

The Enterprise Application Profiler is a feature in Sun's Java Studio Enterprise. It provides developers functionality that addresses their critical design-time performance tuning requirements. You can use this profiler to analyze applications that you develop with Sun Java Studio Enterprise (IDE - Integrated Development Environment) and deploy to the Sun Java Application Server. Using the Enterprise Application Profiler, you can observe component level performance for the Java Enterprise System. You can also selectively profile the methods that are included in the applications deployed in the Sun Java Application Server container. There is a load generator that is included with the IDE. Using this you can generate load on a system and observe the performance profile of a loaded system.

This paper provides an introduction to the Enterprise Application Profiler (Profiler for short) and describes its capabilities.

Downloading and Installing Java Studio Enterprise 8

1. Download the IDE for your platform from the Java Studio Enterprise home page.
2. Launch the downloaded installer
3. Proceed through the steps of the installer to install the IDE
4. Start the IDE

Getting Started

You need to enable the Profiler collector first. To enable Profiler collection, ensure that the Enterprise Application is set as the Main Project within the IDE (indicated by a bold label in the IDE's Explorer). If it is not set as the Main Project, right-click the application's project in the Explorer and select "Set Main Project".

Figure 1: Setting a project as the Main Project

Next, click the "Run" menu and select "Profile -> Enable Collection". If the items in the Profile menu are disabled, the main project is either not set or the project is not an Enterprise Application.

Figure 2: Enabling Profiler Collection on the Main Project

By enabling profiler collection, a bytecode-preprocessor tag gets added to the Application Server Instance's configuration file ("domain.xml"). This also adds the necessary classpath information and adds filters to the Web application's configuration file ("web.xml").

To disable collection, click the "Run" menu and select "Profile -> Disable Collection".

Launching the Profiler from the IDE

Launch the Profiler from the IDE by choosing "Profile-> Open Profiler" from the "Run" menu. The IDE displays the Profiler pane.

Components used by the Profiler

The Profiler contains four major components that work together to obtain performance data for applications deployed on the Application Server:

• An HTTP transaction tracking component that records HTTP transaction details, including performance. There is a load-generating harness, invoked from the Transactions component, that simulates HTTP and other types of client traffic.
• An EJB statistics component that gathers high-level statistics on EJB performance.
• A method-level performance-profiling component to obtain method-level performance data.
• A memory monitor that shows memory use and correlates these values. It has a garbage collection feature that frees memory.

You invoke each of these components through the tabs at the bottom of the Profiler screens. The Profiler tools are invoked through the icons at the upper left of the Profiler screens.

The next four sections examine the component tabs and show you how to use the components to analyze performance.

HTTP Transactions Component

The HTTP Transactions component performs two important tasks:

• It captures all browser-based request and response details. A pie chart displays the various types of requests and reports the Java Enterprise System component that initiated the request.
• It generates an agenda from the requests it captures. This agenda forms the basis for a set of requests for load generation and load testing. Each individual HTTP transaction can be replayed or sent to a harness for load testing.

When you use this component, you can trace an HTTP request in its entirety. You can then save, record, replay, or edit the request or transaction by modifying certain parameters and replaying the request.

The graphical overview of Java Enterprise System that is presented here contains the following elements.

• Component usage, showing how different parts of the application are used in HTTP transactions.
• Chronological request flow, displaying all the HTTP Transactions in chronological order.
• A detailed transaction report that includes Header, Request, Response, Cookie, Session information, and Round-trip time.

Figure 3: HTTP overview panel showing transactions that consume large amounts of resources

The left pane in Figure 3 displays all HTTP transactions in chronological order. The chart on the right pane shows an overview of time spent in various types of transactions.

To examine the details of a specific transaction, select the transaction in the Current Records tree on the left panel. This highlights the corresponding row in the Runtimes Table.

Figure 4: HTTP Transactions sorted by execution time

In Figure 4, the table on the right lists the wall clock time for the execution of each transaction. You can sort this table using one of three metrics:

• Execution time.
• Application component to which the transaction belongs.
• Action taken (GET, POST, and file name).

You can save, modify, and replay these transactions. To perform any of these functions, right-click on the transaction in the left pane and choose the appropriate function.

You can obtain additional details about a transaction that is highlighted by choosing the corresponding tab at the bottom of the right panel. These details include request, cookies, session, context, client and server, and headers information.

Using the Load Generator

You initiate load generation by choosing the Load icon from any of the Profiler panels (except the Memory panel). The Profiler performs load generation by using an internal HTTP client capable of generating HTTP and HTTPS traffic.

HTTP requests from the created agenda are fed back to the server until you stop load generation by choosing the Stop icon.

To initiate load generation, supply two input parameters to the Load Generator:

• The number of clients to simulate. This parameter defines the number of threads that access your application. Note that a large thread number can affect system performance.
• A "think," or idle, time. This duration mimics the time taken between a user's requests within an application to Application Server.

The Profiler automatically creates a Load Generation agenda when you choose the Load button. You can also create the agenda by copying all the records from the Current Records folder into the agenda.

EJB Container Statistics Component

The EJB Container Statistics component gathers performance statistics at various levels of an application's structure. The EJB Container Statistics component specifically performs the following tasks:

• Shows a quick statistical overview of the container immediately after you select the EJB Container Statistics tab.
• Builds an EJB tree from which you can select different levels of statistics, from the server-instance level to the method level.
• Generates statistics appropriate to the different levels in the EJB tree (labeled application, ejb-module, web-module, ejb, servlet, and methods) and makes them available through context menus in the tree.
• Tabulates aggregated execution times, call counts, and error counts of the deployed applications.
• Creates a pie chart of the percentage of resources consumed by the deployed applications.

To access the EJB Container Statistics component and its panel, select the EJB Container Statistics tab in the Profiler. See the example in Figure 5.

In Figure 5, the tree in the left panel represents the available statistics from the container. Right-clicking any node in this tree and choosing View creates a panel showing the statistics for that node.

The charts on the right panel show the system usage by execution time and call counts. They provide a high-level view of system performance.

Figure 5: EJB Container Overview

You can also choose to watch a specific node, referred to as “adding a watch to a node.” By adding a watch to a node, you set its individual refresh rate. The Profiler refreshes all the nodes globally according to the initial setting defined in the connection dialog box. When a watch is set on a node (thus changing the refresh rate) all children of that node inherit the new refresh period.

Methods Component

The Methods component provides the application's view of the data at the method level. You can use the Methods component in conjunction with your analysis of transactions and load-testing or you can use it by itself. Using method-level profiling, you can do the following:

• Initiate and directly use the Method Level profiler without involving transactions and load components.
• Once you launch the Profiler, choose the Methods tab to see the discovery tree and choose a method for application profiling.
• Generate a browser request and obtain performance data for the methods you want to profile in a given application.
• Modify your data selection dynamically and regenerate the discovery tree.
• Save a results tree and retrieve the tree for future reference.
• Sort data according to wall clock execution time or by call counts. The data is displayed in three ways: raw data table, by caller/callee tree, and single screen call stack. To access the Methods component, click the Methods tab in the Profiler. The Methods component opens the Methods panel containing two panes. Figure 6 is an example Methods panel that contains two panes.

Figure 6: Methods panel with method data in a Tree format

The left pane holds a data tree that displays the deployed applications from which you select an application for profiling. The right pane displays performance data in a Tree format sorted by wall clock time.

Instrumenting Methods
When the Methods tab is first selected, it appears with the deployment tree on the left panel. Expanding this tree displays the applications deployed in the Application Server instance for which the profiler is collecting data. To specify the methods to examine - also referred to as “instrumenting” selected methods, select the Instrumentation button (indicated by a red check mark). This action brings up a writable copy of the deployment tree. After selecting the methods to instrument, select OK. Note that if a node in the deployment tree is selected for instrumentation, the children of that node are also selected. You have the option to deselect the child nodes. This selective instrumentation is unique to this Profiler. Selective instrumentation reduces profiler overhead and thus leads to more accurate results.

Figure 7 is an example of a writable deployment tree from which you can select methods.

Figure 7: Writable deployment tree to select methods for instrumentation

Generating Method-Level Performance Data
Once you have completed method and application selection for performance profiling, you can generate method-level performance data by one of two methods:

• Use the Transaction Panel's derived agenda and the built-in load-tester (as described in Section 3.2) to generate load data and to obtain performance data.
• Use a browser to send a single request, or use any Java technology client to access the application. This creates a method tree that shows the time spent on various methods within the application.

The performance data is displayed in a table by default. It can also be viewed as a tree, or in a call graph. Figure 8 shows the performance data in tabular form. If the source code is available, double-clicking on a row shows the source. You can also right-click on the method name and select "Warp to Source".

Figure8: Methods Panel with Execution Times table

The Call Stack Graphical representation of this performance data is shown in Figure 9. If the application were complicated, the entire call stack would fit on one screen. This is important to determine the accuracy of the call stack.

Figure 9: Methods Panel with a Call Stack

Memory Monitor Component

The data for the Memory Monitor is extracted from the Application Server and sent to the Profiler – which is run on a different Java Virtual Machine. As a result, you must allow initialization time (of a few seconds) for the Memory Monitor before the plot shows correct data.

The Memory Monitor component measures the maximum allocable, free, and used memory in the Application Server. It correlates these values to inform you when memory limitations are being reached. The Memory Monitor component probes the Application Server for memory data and displays it over time.

You access the Memory Monitor component by choosing the "Memory" tab in the Profiler. The Memory Monitor panel is shown in FIGURE 10.

Figure 10: Memory Monitor panel that shows the HEAP usage of the JVM that controls the Application Server

From this panel, you can select the Run Garbage Collection button to enable the Application Server to perform garbage collection and thus free necessary memory resources.

Profiling a Sample Application

Let us now follow a complete example of profiling and tuning a sample application, "Speed Reader. Through this example, you will learn how to:

• Enable performance collection in the IDE.
• Deploy the SpeedReader Demo and analyze its performance.
• Tune the SpeedReader Demo application.
• Redeploy the application and examine improved application performance.

Follow these steps to use the "SpeedReader Demo.

1. Download and install Java Studio Enterprise 8 from the Sun Download Center, or install it from your CD.
2. Download "SpeedReaderDemo from the Sun Java Studio Enterprise Developer Resource site (provided in the Referenced section). Extract the demo from its zip file into a location you specify with the $DEMO_HOME variable on your machine.
3. Start the Java Studio Enterprise 8 IDE.
4. Open the "SpeedReader Project.
5. Set the "SpeedReader project as the main project. Note that the IDE might already have set the "SpeedReader Project as the Main Project, (as indicated by a label in bold in the IDE)

Figure 11: Open the SpeedReaderDemo project and set it as the Main project

6. Enable Profiler collection by choosing "Run -> "Profile -> Enable Collection. A dialog appears informing you that the next time you deploy or run the application, the Application Server will restart.
7. Deploy "SpeedReader to the Application Server.
8. Open the Profiler feature in the IDE, by choosing "Run -> Profile -> Open Profiler command. A message on the right panel of the Profiler states that the SpeedReader Demo has not generated any transactions. If you get a message saying that the Application Server is not running, you can check the Application Server's status from the Runtime tab in the main IDE Explorer panel, and restart the Application Server.
9. If the Application Server is running properly, you can run the SpeedReader Demo. To run the Demo, select appropriate fields in the SpeedReader application. For demo purposes, do not select the "Finish button on the last page at this time.
10. Examine the results obtained by running the SpeedReader Demo on the HTTP Transactions Panel. The Overview panel provides a snapshot of HTTP traffic.
11. Choose the Runtimes Table in the HTTP Transactions Panel. Notice that the "TextProcessServlet dominates execution time. You can also examine the data provided in the Per Transaction Details panel.
12. Now choose the EJB Container Stats Panel. If the right chart panel does not contain two pie charts that provide an overview of the container's performance, choose the "Update EJB Tree button on the upper left corner.
13. Expand the "Applications tree; right-click "TextProcessBean and select "View. Details of the EJB appear in the data panel. Notice that all program execution is occurring in the business method "getNextLine.
14. Now choose the Methods panel. Expand the "Applications tree to view the deployment structure of applications in the Application Server. This tree is read-only.
15. Select the Instrumentation (red check mark) button to display a copy of the deployment tree. Choose the methods you want to examine. For the purposes of this example, choose all displayed methods by checking the top level node in the deployment tree and select "OK.
16. Select the "Load button located on the right above the tree in the Methods Panel to load the application methods with the Load Generator. Wait one minute, and choose the "Stop button.
17. Choose the "Get Method Trace button to display the method data in the Profiler.
18. Examine the data panels. Notice that the bulk of time is spent in the "processRequest method in "TextProcessServlet.
19. Save the Methods Tree to establish a base for providing a comparison after you finish tuning the application.
20. On the Execution Times Table, double click on "TextProcessServlet.processRequest(...) to examine the source.
21. Find the call in this "processRequest method that calls "getNextLine("int). This is a business method of "TextProcessBean.
22. Find the call to "getNextLine("int) by pressing control-click on the "getNextLine method.
23. Right-click the interface class name ("TextProcessLocalBusiness) and select "Find Usages. A panel appears at the bottom of the screen with the places in the code where this interface is named. Double-click on the implementation of this interface to obtain the source.
24. Use the navigation panel or scroll down, find the "getNextLine("int) method.
25. The call to "worseMethod is in the "getNextLine method. You can see that the method is doing I/O in an expensive way. This is the reason the application is performing poorly.
26. Change this call to "betterMethod by commenting the "worseMethod and uncommenting "betterMethod.
27. Compile the SpeedReader Project by right-clicking the SpeedReader Project node and choose "Clean and Build Project.
28. Deploy the SpeedReader Project by right-clicking the SpeedReader Project node and choosing "Deploy.
29. Use the Load Generator to generate a load on the Application Server.
30. After stopping the load generator, examine the data. Notice a marked improvement in the application's performance.

References

The following product pages offer a wealth of additional developer-oriented resources:

• Sun Java Studio Enterprise
• Developer home
• Java Tools

Conclusion

In this article, you learned how to use the Enterprise Application Profiler in Sun's Java Studio Enterprise 8 to address critical design-time performance tuning requirements. You also saw this in action through an example code. Note that there is a separate Java Profiler available as a plugin to the NetBeans IDE. This lets you track thread state, CPU performance and memory usage of a Java application. There is a separate article on the NetBeans Profiler that is available.

About the Author

Prakash Narayan has worked at Sun Microsystems for over 15 years. He initially worked in the area of high performance computing, and he now devotes his time to enterprise Java. He is currently a senior engineering manager in the Sun Java Studio Enterprise team with responsibility for components in the life cycle of enterprise application development.