|
|
|
Published January 2006
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.
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".
Launch the Profiler from the IDE by choosing "Profile-> Open Profiler" from the "Run" menu. The IDE displays the Profiler pane.
The Profiler contains four major components that work together to obtain performance data for applications deployed on the Application Server:
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.
The HTTP Transactions component performs two important tasks:
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.
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:
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.
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 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.
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:
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.
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:
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:
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:
SpeedReader
Demo and analyze its performance.
SpeedReader
Demo application.
Follow these steps to use the "SpeedReader Demo.
Figure 11: Open the SpeedReaderDemo project and set it as the Main project
References
The following product pages offer a wealth of additional developer-oriented resources:
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.
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.