Java Performance Tuning

Java(TM) - see bottom of page

|home |services |training |newsletter |tuning tips |tool reports |articles |resources |about us |site map |contact us |
Tools: | GC log analysers| Multi-tenancy tools| Books| SizeOf| Thread analysers| Heap dump analysers|

Our valued sponsors who help make this site possible
JProfiler: Get rid of your performance problems and memory leaks! 

Training online: Concurrency, Threading, GC, Advanced Java and more ... 

The Interview: Lax Sakalkale OptimizeIt

Get rid of your performance problems and memory leaks!

Modern Garbage Collection Tuning
Shows tuning flow chart for GC tuning

Java Performance Training Courses
COURSES AVAILABLE NOW. We can provide training courses to handle all your Java performance needs

Java Performance Tuning, 2nd ed
The classic and most comprehensive book on tuning Java

Java Performance Tuning Newsletter
Your source of Java performance news. Subscribe now!
Enter email:

Training online
Threading Essentials course

Get rid of your performance problems and memory leaks!

Back to newsletter 039 contents

This month we interview Lax Sakalkale, Senior Product Manager of the Optimizeit performance solutions at Borland Software Corporation. Our interviewees are always well informed about Java performance, and usually give highly interesting and useful insights to the Java performance community. And this time we have Lax giving us almost a manual of how to proceed to ensure you achieve good performance in your project, especially noting which pitfalls to avoid. Read on...

Q. Can you tell us a bit about yourself and what you do?

My name is Lax Sakalkale and I am the Senior Product Manager for the Optimizeit(TM) performance solutions at Borland Software Corporation. My role has been to help customers - both individual developers and at the Enterprise level - to manage the performance of their Java and J2EE applications, offering a best practice approach along with the best technology available to achieve this in the most efficient way possible.

Q. What do you consider to be the biggest Java performance issue currently?

The quick answer is memory leaks!

However, a more insightful answer would be to take a look at the use of J2EE in enterprises today. J2EE has pretty much become the de facto standard for enterprise application development, leveraging the speed, security and reliability of the technology. However the reality for developers and QA teams is that the pressure is on them to build these applications with greater speed and performance, in less time and with fewer resources. I would therefore say that the biggest Java performance issue at the moment is being able to cut through the complexity of J2EE architecture to get a true understanding of the performance behavior of the entire application. From here the challenge is being able to swiftly locate the exact root cause of any performance issues - without causing any delays to the project!

Q. Do you know of any requirements that potentially affect performance significantly enough that you find yourself altering designs to handle them?

Key requirements that significantly affect performance are areas such as volume of load, number of users, and response rate times. Designing for high performance requires the use of object-oriented concepts like encapsulation, inheritance and polymorphism to ensure that the system is flexible and scalable throughout its lifecycle. Requirements need to be modeled right from the early stages of the application's lifecycle. Simply put, if the application isn't designed from the outset with these performance requirements in mind, then ultimately it will result in late stage rework or deployment disasters - an outcome that no one wants to deal with.

Q. What are the most common performance related mistakes that you have seen projects make when developing Java applications?

One of the most common performance related mistakes that I've seen in projects is not so much technical errors, but quite frankly the approach that development teams take to managing the performance of their applications. The biggest mistake is when developers don't realize how early in the development process they need to start profiling their code. The tendency to leave performance tuning right until the end causes delays, problem escalations, and the kind of deep-rooted performance flaws that can sideline an entire project or create business disasters once an application is live with customers in a production environment.

The logic behind regular performance tuning throughout development is straightforward; nobody understands a piece of code as well as the person who creates it, and nobody is better positioned than the developer to efficiently make improvements in the logic and implementation of that code. I like to consider performance profiling as the "Java developer hygiene".

Another important oversight that I've seen many organizations make is not empowering test engineers with the right tools to help them diagnose system-wide performance issues; they need to be able to capture performance diagnostic information in a way that the developers can really use to resolve the problems swiftly. Poor communication between test and development teams is responsible for a lot of the delays and setbacks that projects encounter so achieving a seamless developer hand-off is very critical in managing performance.

Q. Which change have you seen applied in a project that gained the largest performance improvement?

For every Java development project the ability to understand the performance behavior of an application and to isolate and diagnose problems with pinpoint accuracy can have a huge impact on the overall performance of the application. One customer that we've been working with spent 3 weeks trying to hunt down a memory leak; the application kept crashing and hanging and was threatening to jeopardize the entire project. They managed to solve the leak in just a few hours using Optimizeit Enterprise Suite; moving forward they've decided to make performance tuning a regular part of their development process - an important change in their approach that will help to avoid such a crisis occurring again.

Q. Have you found any Java performance benchmarks useful?

From the perspective of performance profiling, an important benchmark is measuring the overhead that your profiling tool adds. Maintaining low overhead is a crucial requirement for Java profilers as excessive overhead can distort the actual performance of your code, causing you to misdiagnose where problems lie, or may cause you to miss critical problems entirely.

We benchmark the overhead of the Optimizeit performance tools using VolanoMark. This is a pure Java server benchmark characterized by long-lasting network connections and high thread counts. The VolanoMark benchmark simulates a multi-threaded server under load, enabling you to compare the average number of messages transferred by the server per second. Clearly, the more messages transferred by the server per second, the better. I'm pleased to add that Optimizeit solutions have consistently proven to have extremely low overhead.

Q. Do you know of any performance related tools that you would like to share with our readers?

Absolutely! I would definitely like to recommend Optimizeit Enterprise Suite to any Java or J2EE developers. Many folks are familiar with Optimizeit Suite that includes the Profiler, Thread Debugger and Code Coverage.

However I would like to highlight a new component of Optimizeit Enterprise Suite called Optimizeit Request Analyzer that is designed to make J2EE performance management much easier for developers. It allows developers to analyze the performance behavior of code across J2EE application tiers. Using Optimizeit Enterprise Suite developers can efficiently prioritize the performance of JDBC, JMS, JNDI, JSP, RMI, and EJB web requests, as well as address code level performance issues such as memory leaks, CPU bottlenecks, thread issues and so on. Precise drill-down capabilities make it easier to diagnose and locate the root cause of performance problems right down to the offending line of source code.

Q. Do you have any particular performance tips you would like to tell our readers about?

Simply this - optimize your code as you go for speed, reliability, scalability and maintainability. By devoting just a small amount of energy throughout the development process to address and correct performance obstacles, you can save yourself a lot of late stage re-work and frantic troubleshooting.

And of course - make sure you try Optimizeit Enterprise Suite! Many of the painstaking processes of tracking down and solving performance issues have been automated or made easier so you can save yourself a huge amount of time and effort.

(End of interview).

Back to newsletter 039 contents

Last Updated: 2022-11-29
Copyright © 2000-2022 All Rights Reserved.
All trademarks and registered trademarks appearing on are the property of their respective owners.
Java is a trademark or registered trademark of Oracle Corporation in the United States and other countries. is not connected to Oracle Corporation and is not sponsored by Oracle Corporation.
RSS Feed:
Trouble with this page? Please contact us