It is commonly said that 90% of performance problems are caused by 10% of the code. Therefore, the only way to really get good gains in performance is to tune that 10% of code. Tuning the other 90% is a waste of time because it is ultimately responsible for very little of the problem. The big question is: How do we know which 10% to tune? The answer is to use a Profiling tool. Profiling tools help us identify the bottlenecks in our applications by tracing and reporting performance metrics on a very granular scale (usually down to the method). Therefore, we can easily determine which parts of the system are taking the most time and therefore causing us the most problems with performance. There are many Profiling tools available such as JProbe and Borland Optimizeit. Unfortunately none of the good tools are OSS so be prepared to shell out some bucks... it is definitely worth it. Once we have our Profiling tool we are ready to rumble right? Hold on Cowboy! Before you even begin to tweak code for performance issues you need to be able to measure performance and ideally you want to set a performance goal to work towards. To measure performance you will need yet another type of tool. This next tool needs to allow you to create repeatable performance tests and is normally referred to as a Load Testing tool. There are many of these available... one such tool is The Grinder (an OSS product). Now that we have our trusty Profiling tool and Load Testing tool in hand we can begin our journey. First start by creating a series of performance tests against your current system. The results of these initial tests will be your "baseline". You may even find by the end of this process that performance is actually good enough for your needs. If so, then stop there.... no need to continue. However, if your tests clearly show that performance is not up to snuff then it is time to start profiling. Take each test case one by one and profile to identify the bottleneck areas. Once those areas are identified you can begin to tweak the code. The important part here is to make only small changes and run the performance tests and unit tests (you do have unit tests right?) after each change. If the tests do not show an improvement in performance compared to your baseline than your changes had no effect and they should be rolled back. Continue this process until you have increased performance to the necessary level or you feel that you have reached the maximum performance for your given setup without significantly re-architecting the system. This may take a significant amount of time depending on the size of the application. The important part you want to keep in mind throughout this process is that you should not be changing the funtionality of the code... only the performance characteristics. If the code is not very malleable to these changes than you may have to perform quite a bit of refactoring before you can even start to worry about performance. A well-factored application is easy to profile and performance tune... a poorly factored one is not. Performance tuning is really just a systematic exercise of profiling the application for bottlenecks and then making small changes to the identified bottleneck areas and measuring the difference. Rinse and Repeat until you have achieved your desired performance level. Performance tuning without profiling and repeatable tests is nothing more than guessing. [ February 26, 2004: Message edited by: Chris Mathews ]
My recommendation is to read the book Performance Analysis for Java Websites by Stacy Joines, et. al. It walks you through all of the issues involved not only in finding and eliminating commmon performance bottlenecks in Java Websites, but also gives you direction and guidance in things like capacity planning and network architecture for maximum utilization of your resources. Kyle
JAMon is a nice open source java performance and scalability measuring tool. It is also very easy to use. The demo comes with a Servlet filter that will track the following statistics for all JSPs, Servlets, and other file resources such as html, GIFs, JPGs, .... The filter tracks hits, total execution time, avg time, min time, max time, std dev, and a number of other metrics such as the current number of outstanding requests for the resource as well as the max and avg. All the statistics are viewable via a sortable HTML table. Check it out at http://www.fdsapi.com. There is a live demo that gives you a feel for what JAMon can do for you.