by Josh Juneau

Incorporate performance tuning into your development lifecycle.

Java Magazine March/April 2015 Edition

Imagine that your application, after months of development time and lots of testing, is finally ready for production deployment. The application goes live, and for the first few minutes everything seems like a success.

Suddenly you receive a phone call from one of the users telling you that they can’t access the application, because it appears to load indefinitely. Moments later you receive another call, and yet another. It seems as though your application doesn’t allow concurrent access to enough users. This is a nightmare scenario in which the application development team must make critical performance tuning decisions under the gun, and they must make each of the changes to the production environment directly.

Where do you begin in this situation? What could be wrong? Is a server configuration preventing enough connections for your production environment, or does the application code contain a bottleneck that causes the users to wait?

Many applications are not tuned for performance until after they’ve been put into production. Unfortunately, many organizations do not deem performance tuning to be an essential part of the development lifecycle, but rather, treat it as a triage step when things go wrong. To make matters worse, Java EE performance tuning can sometimes be much like finding a needle in a haystack. The cause of the performance issue can lie just about anywhere, from the application source code to a server configuration.

In this article, you’ll see some of the processes that you can use for tuning your Java EE applications pro-actively, so you can try to avoid scenarios like this one.

Approaching the Beast: Proactive Tuning

Performance tuning should be made part of the standard development lifecycle. As such, applications should be designed from the ground up with performance in mind. To be forward-thinking about performance means to consider carefully all approaches for the implementation of application solutions, not just the fastest approach or the one that is easiest to implement. Java EE applications can be particularly difficult to develop around performance, because several points of contention in a Java EE environment can add performance burdens to an application.

The top performance issues experienced in Java EE application environments tend to be related to configuration issues and environment issues. Oftentimes, the applications themselves are coded fine, but the application server to which they are deployed is not tuned correctly or it is configured inappropriately for the applications or the intended user capacity.

To tune properly for a production employment, perform the following steps in the order listed:

• Application tuning
• Server tuning
• Java runtime tuning
• Server operating system and platform tuning

Next, focus on decreasing the chance of incurring performance issues after a production deployment.

Coding for performance. There are bevies of coding situations that might lead to performance overhead in a Java EE application. Java EE applications are executed concurrently, which can lead to bottlenecks, because users might be competing for resources such as web services or databases. Each remote call can add latency, and processes such as serialization can be CPU-intensive, causing further performance degradation. With these kinds of issues in mind, you need to craft Java EE applications carefully, ensuring that proper resource handling is used.

An application’s performance tuning should begin with the source code. Even though the top causes of performance issues in Java EE applications point to the environment, proper coding can still play a key role in an application that performs well.

The following poor-coding practices, among others, can lead to performance issues:

• Over-serialization and deserialization
• Overuse of finalizers
• Too much synchronization
• Not discarding unused variables
• Too many dynamic variables
• Rampant use of System.out.printIn()
• Sessions that are not released when they are no longer needed
• Failing to close resources (for example, database and network connections)

Performing code reviews is imperative for reducing code that inhibits an application’s performance. While poorly crafted code can slip past multiple developers, the more eyes that examine it, the better. In addition to code reviews, more than one individual should run performance and load tests against an application, and compare results of current tests to those run previously.

Read the full article in Java Magazine at oracle.com/javamagazine