|
|
|
|
Published January 2003
WebSphere Studio provides a profiling tool for identifying and
isolating performance problems such as performance
bottlenecks, object leaks and system resource limits.
The tool targets applications of all levels of complexity,
from simple standalone java applications to complex enterprise
applications running on multiple machines and on different platforms.
Based on the Remote Agent Controller architecture, the WebSphere Studio Profiling
tool is capable of reconstructing the application execution path and displaying
the interaction of business components such as Servlets, EJBs and JSPs.
The tool collects execution information at the class instance and method invocation
level.
Being tightly integrated within the Eclipse project, the tool is also easy to extend. That means that users can plug in their preferred views to analyze the data, or can extend the data collection metaphor by implementing their own flavor of data collection agent.
This article provides an introduction to the WebSphere Studio Profiling tool and shows how it can be used to profile an enterprise application and how to analyze the data using various statistical and graphical views.
The WebSphere Studio Profiling tool provides a powerful user interface for profiling an application and for analyzing the profile data. A set of statistical views helps you identify performance hot spots at the package, class or method invocation level. The tool also provides a set of graphical views which helps you better understand the application execution, at the nodes, processes, threads or method invocation level.
Profiling of collected data is managed by the Remote Agent Controller (RAC) architecture. The Agent Controller's deployment model is made up of multiple development hosts which use the test client to interact with multiple applications residing on many different hosts on the network.
A simple deployment diagram is illustrated below:
The test client sends all its profiling requests to the Agent Controller on the host that contains the application. It is on the deployment hosts that these requests are authenticated and routed to the target agent or service. Commands and data that are generated by the agents and services must also be routed to the Agent Controller, from where they are then transmitted to the test client.
RAC controls the collecting of profiled data using different types of agents, such as Java Profiling Agent and J2EE Request Profiler Agent.
A Java Profiling Agent runs in a JVM process and receives notifications of JVM events, based on the JVMPI (Java Virtual Machine Profiler Interface). A J2EE Request Profiler Agent resides within the application server process, with the purpose of collecting data from the interception points of the e-business application request, such as EJB and Web Containers.
As the profiling tool is integrated with WebSphere Studio , there is nothing more to do but accept to install the Remote Agent Controller when installing the product. Because the application to be profiled can be running on a different host than your deployment machine, make sure that the Remote Agent Controller is installed on the host where the application is running. Remote Agent Controller can be installed separately from the WebSphere Studio product.
The Online Auction application is a sample which comes with WebSphere Studio. As the name implies, the sample application features an auction Web site, where you can browse auction items, submit items for sale, and bid on items. Since the online auction sample application employs J2EE technology, it features a wide variety of application components, such as Java beans, JDBC, HTML, JavaScript(TM), servlets, JSP pages and enterprise beans.
In this article we will focus on the set of profiling views that can be used to solve a specific performance problem: an inexplicably large time to execute the first transaction compared with the time spent to execute the rest of transactions. There are some other equally important views, used to find memory leaks or memory related problems which are not going to be discussed in this article.
We are going to profile a few transactions and than use the profiling views to find the performance hot spots. The Package Statistics view is a good starting point because it identifies the packages responsible for slow execution time. From here, we can drill down and look for the class or method being responsible for the execution poor performance.
As you can see in Figure 2, the Package Statistics view shows statistics of the different classes, grouped by their containing packages. The view can be customized to display any type of statistical data, such as memory allocation, or time based statistics.
In this particular sample, we are only interested in execution time, so we are going to sort the packages using the execution Base Time column. As you can see in Figure 2, the com.ibm.ws.ejbpersistence.dataaccess package is the one identified to be the execution hot spot. Even more, you can see that within this particular package, DataAccessRequestImpl is the class responsible for the slow execution time.
Once we get this information, it is time to drill down to the Class Statistics view and identify the method responsible for the class's overall poor performance.
Figure 3 shows the Class Statistic view. Now we can very clearly see that the execute method is the one responsible for the DataAccessRequestImpl class's poor performance. Notice that the method execution time is very high compared to the time spent in the executeOneRowFBPK method.
Let's stop for a moment and look closely at the Class Statistics view. There is one really interesting thing worth noticing while we are here. As you can see, the java.text.NumberFormat class is next on the list of classes responsible for slow execution time. And in particular the java.text.NumberFormat.getCurrencyInstance() takes up the time spent in that class. This can give you an idea of what it costs to use some apparently simple methods. Even if NumberFormat.getCurrencyInstance() seems to be a simple API, calling it a lot of times in your code can hit your application overall performance.
Let's move along now and analyze the method invocations for the DataAccessRequestImpl.execute() method. A powerful feature of the profiling tool is the graphical representation of the application execution. You can see the method execution at the method invocation level. This view is useful when you are looking for performance problems because you can see here the execution pattern and differences between invocations of the same method.
Figure 4 shows the Method Invocation view displaying the invocation of the DataAccessRequestImpl.execute() method. You can graphically visualize the method invocations, see who called this invocation in the execution stack, or jump to the method source code.
The Method Invocation Table shown in Figure 5 displays the method invocations in a tabular format. It's interesting to notice that for the first method invocation the execution time (see the Cumulative Time column) is very high compared with the rest of the method invocations.
Analyzing the method invocations execution stack, we can find the reason why
this specific invocation was slower than the rest of the method executions.
Looking at the method invocations pattern, we find that the first call to the
OnlineItembean.FindByValue(IndexedObject) method take a lot more
time than the rest of the method invocations.
We finally found the method responsible for the overall execution slow time, and this is
the first invocation for the OnlineItembean.FindByValue method.
WebSphere Studio Profiling tool is a powerful, yet very easy to use tool. It can help you find a wide range of performance problems, from performance bottlenecks, object leaks to system resource limits. For this specific scenario, the WebSphere Studio Profiling tool helped us to identify the invocation responsible for the execute method's overall poor performance.
The tool targets applications at any level of complexity, from simple standalone java applications to complex enterprise applications running on multiple machines and on different platforms.
Being tightly integrated with WebSphere Studio, the profiling tool allows developers to test application performance early in the development cycle. Using the Profiling tool reduces risk early in the development cycle and avoids problems in the final performance tests.
