|
|
URL of the article:
Accelerate Your Java Code
Optimizing Your Applications with Enerjy Performance Profiler
by Brian Deeley
This article is aimed at developers and architects who are currently developing Java applications, or have developed applications, and want to optimize them for speed or throughput. The author explains why profiling techniques should be adopted and focuses on the use of Enerjy Performance Profiler to aid in this methodology.
Introduction Your team has spent the last few months designing and coding the "next best" Java application. Your customer has been satisfied with the updates throughout the project and Load Testing has proved the application is robust. However, one of the requirements is a performance-based target that requires the information to be returned to the user at a rate that is currently unobtainable by your application. Performance issues found in testing can arise in numerous ways; lack of network bandwidth, hardware limitations, memory issues and poor design are just a few of the examples encountered in development and testing. The way an application has been written may also be an issue, and before the other areas on the list are examined, examining your code at run-time will give you confidence that your code is not a factor. Inexperienced developers may not be coding to optimal performance and although many bottlenecks and code quality issues are rectified at the 'code review' stages in the project lifecycle, some bottlenecks may slip through the net if the code review is a manual process and the application is large. Historically, developers could afford to compromise the speed of an application due to slower network speeds and the expectations of users. With emerging technologies and media coverage, network speeds and user expectations are increasing rapidly. Streamlining the code, and code efficiency, are becoming increasingly important. Introducing Enerjy Performance Profiler Performance benchmarks and application profiling are usually left until the end of a project when functionality and the aesthetic look and feel have been completed. Urgent demands of deadlines and last minute changes by the customer can lead to profiling and tuning being frequently pushed aside. With the integration of Enerjy Performance Profiler into your development environment, performance profiling is no longer a grueling process of configuration and presumption. Instead, you are provided with a simple, flexible tool that not only seems like a natural extension to your IDE but also keeps you one step ahead of potential problems. This allows the project manager to be aware of any possible time increase, budget for it, and inform the customer. Enerjy Performance Profiler uses a native interface to the JVM (the JVMPI) to get profiling information from a running Java application. This information is returned to the user in a clean, streamlined table format that can be easily examined to find performance bottlenecks in your code. Enerjy Performance Profiler monitors your program as it runs and collects detailed timing information about how much time is spent in selected methods. This enables you to focus your optimization efforts directly on the areas of code that have the most impact. Since early on, the mindset of the Enerjy engineers was to provide developers with easy to use tools that help to improve the code without being intrusive. The configuration of Enerjy Performance Profiler is an excellent example of this. As long as an application has been compiled within your IDE (or running on a server) it will be available to be profiled. As Enerjy Performance Profiler runs within your IDE there are no external configuration files or separate profiling projects to set up. To run Enerjy Performance Profiler from within your IDE just select Run, Profile Configuration, Performance, and the application you wish to profile (Figure 1).  Fig. 1: Running Enerjy Performance Profiler from your IDE After you have decided where to focus the profiler within your application, the Enerjy Performance Profiler window will appear and you will be able to select a method or group of methods from your application. Either select a main() or run() method to profile the whole application or, if the application is large or you want to focus on a particular area, select the necessary methods. The methods in your application are displayed in an easy to read tree structure shown in Figure 2.  Fig. 2: Selecting methods to profile and package filters After choosing a method you will be able to include or exclude other packages in the profile data collection. Enerjy Performance Profiler can generate data about methods over which you have little control. Here you can instruct the profiler to ignore these packages and to focus primarily on your own code. Every package in your path will be available to either include or exclude from your results. You will almost always want to include the package of the code you are profiling, but excluding some of the java.* or javax.* packages can make your results much clearer to analyze. And that's it! Click OK and start your application allowing the Profiler to collect the data behind the scenes and use the Snapshot button to generate dynamic snapshots of data throughout the life of the application. Unique Features When using profiling tools, overhead is always a concern as using any tool with your code at run-time will always consume some resources. Enerjy Performance Profiler uses a unique adaptable profiling technique known as 'On-The-Fly Profiling'. Notice the checkbox Begin collecting data on application start on the configuration window (Figure 3). By switching this off, Enerjy Performance Profiler is started and attached to the JVM, but does not begin profiling anything and therefore does not consume resources. If you are profiling J2EE applications, where is the benefit in profiling the Application Server start up process? (Unless you are building an Application Server!) Test results also show that starting the Application Server with a profiling tool running can result in the start up process taking between three and ten times longer.  Fig. 3: The 'Begin collecting data on application start' Box Once the application has started and you have got to a point where you may be concerned about performance (or just interested in the results) hit the wrench icon (Enerjy engineers like to call it the 'Lobster Claw'!) and specify the methods you wish to profile. This ensures the minimal overhead involved is only active on the parts of the application you are concerned about.  Figure 4: The 'Lobster Claw' Button Using this on-the-fly procedure you can actively refocus the profiler as you run through the application, dynamically taking snapshots and refocusing as and when necessary. In the past this was a time-consuming process as every time you needed to refocus a profiling tool on a different part of an application you would have to stop the application, stop the application server (if J2EE based), stop the profiler, reconfigure the profiler, restart the application server, and restart the application - Phew! Imagine profiling five or six different areas in one applicationEnerjy Performance Profiler eliminates this laborious process. Analyzing the Results As the Enerjy Performance Profiler runs, the 'Status View' appears displaying a graph of the current memory usage and the state of each system thread in the JVM. From this view you can request a snapshot, reconfigure the profiler through 'On-The-Fly Profiling', and pause and resume all threads. You can dynamically take a snapshot at any point in your application. When the application is complete a final snapshot is taken by default. Enerjy Performance Profiler displays timing results for each profiled method in a searchable tabular format. The table can be sorted by any of the column headings. Click on any method in the main view and the methods called are displayed in the outline pane. Double-click on any method and you are taken directly into the source code at the entry point for that method.  Fig. 5: Displaying results with Enerjy Performance Profiler The results are displayed in both percentage of time and real time (milliseconds) that a particular method has taken against the Profiled method selected. Therefore, whatever method you select to be profiled should be listed at 100%. Its children (other methods called) plus the activities within itself [for example; setting variables or using loops (listed as 'self' in the results)] make up this 100%. Percentages of time are more useful if you are comparing results running on different systems. Obviously the speed of the CPU and the amount of physical memory in a machine can result in faster or slower actual times being recorded but the percentages of time should be comparable. By right clicking on the result table you can edit the columns to include more detailed metrics such as Minimum time and Maximum time for particular methods. When approaching performance tuning, use the Enerjy Performance Profiler results sorted by '% Time'. Review the first methods taking up the most CPU cycles. Focus your attention on methods you feel will either be the quickest to optimize or where you believe an inappropriate amount of time is being spent; for example, a 'read' method taking more time than a corresponding 'write' method. Double click on the selected method, review the code and make the necessary changes. Profile again and hopefully you will find improved performance. Because Enerjy Performance Profiler integrates so naturally with your IDE, this process becomes efficient and habit forming. Comparing Snapshots Each snapshot you take is stored in the project directory on your hard drive. This makes it easy to compare snapshots between builds and measure the performance improvements from within your IDE. Another convenient way to compare profiling results is to look at them side by side in a reporting tool. Simply right click on any point in the main view and select Export table to external file. If you specify a .csv file extension, you can read the file using a spreadsheet tool such as Microsoft Excel. In the example below (Figure 6) we are comparing snapshots to determine how much faster SAX is versus DOM.  Fig. 6: Comparing snapshots to determine how much faster SAX is versus DOM Over time these snapshots can prove how performance profiling has increased the speed or throughput of your applications and justifies any time spent in performing this tuning activity. Remote Profiling Enerjy Performance Profiler can easily be configured to communicate with profiling sessions that do not originate from within your IDE. These profiling sessions can be external processes run on the same machine, or processes launched from any network-accessible computer. To profile an external JVM, download the Remote Profiling Module and install it on your server or other external computer. When starting the remote process you must include a one-line argument to the JVM (the IP address of the machine that is running your IDE, and a port number for a socket to communicate on). In the case of an application server this argument is passed in as a JVM Environmental Variable. Once the external application is started, the full complement of Enerjy Performance Profiler features can be used to profile these remote applications. Proactive Profiling For Added Value Performance profiling naturally leads to performance tuning. Using the profiling methods can increase the throughput or speed of your application. Sometimes this increase may not be required as part of the specification but can lead to better value add for your customer. An example:
*255 days = 365 days less public holidays and weekends. Taking into account the cost of the tool and the cost of man-hours, the return on investment is exceptional! Performance Awareness: You Know It Makes Sense In 2004, trade shows, technical seminars, and Java exhibitions have witnessed a steady increase of interest in this area, with vendors and developers flocking to the relevant booths. Furthermore, even articles and feature points within other articles, that are not directly associated with profiling or performance tuning, have gained popularity. Most applications in use are not running as fast as they could. Throughput is never as high as it could be. The simple reason for this being that the first release of an application is never the most optimized. In the industry, customers (internal and external) are expecting to see profiling/performance tuning stages in the Project Plan and project managers are budgeting for it. As developers, you are ultimately responsible for the code base so you will have to decide how to approach this, armed with the right tools. IDE Support Currently Enerjy Performance Profiler supports the following IDEs:
About Enerjy Software Our Tools: Enerjy's suite of Java tools strives to provide tactical, comprehensive, andat their heartuseful solutions for the everyday Java developer. Our tools keep you inside your IDE, where you spend eight (ten?) hours a day, and get you back to your curly braces and semicolons, where the work really matters. You'll get simple-to-read tables and easily recognized graphs, and you'll always be a double-click away from your code. Our Company: You'll find that we're a little different from other software tools companies. Instead of trying to sell you everything, an all-encompassing development solution, we're maniacally focused on giving you just the help you need, when you need it, and then getting out of your way. And we won't charge you an arm and a leg for our tools. We've built the company from the ground up with a view to keeping costs under control and passing those savings on to you. About the Author Brian Deeley: Brian Deeley is a Java Sales Engineer for Enerjy Software. He previously worked for GE Medical Systems in the diagnostic imaging group before joining Matrix Consultants as a Java Architect. Brian holds a bachelors degree in Engineering from the University of Massachusetts, USA. Reference Enerjy Eclipse Release 2.x or 3.0, from the Eclipse Foundation JBuilderTM Release 7, 8, 9, X, 2005, from Borland WebSphere Studio Application Developer Release 5.x, from by IBM Oracle9i JDeveloper Release 9.0.3 or JDeveloper 10g Release 9.0.5.2, from Oracle Corporation NetBeans Release 3.4.x, 3.5.x or 3.6, from NetBeans.org SunTM ONE Studio 4 or 5, from Sun Microsystems |
||
|
