As promised last week, I am continuing the countdown of Enterprise Java performance problems. Today it's number 9.

An incorrect application server configuration can have such a detrimental effect on the performance of your application, that it pays to learn about the options your application server and its JVM offer to tune their performance.

The J2EE specification can lull the developer into a false sense of security, thinking "As long as I make sure my code is J2EE compliant, it will just run". Most likely it will run, but not necessarily perform very well! Developers should not just throw their EAR file over the wall; developers and application server administrators need to work together on this. The first has knowledge of the application, the latter knowledge of the application server.

Some of the most important things to not leave at their default setting are:

• JDBC connection pools and data sources; initial and maximum capicity, connection timeouts, connection testing options, prepared statement cache. JBoss 4, BEA WebLogic 9.2, IBM WebSphere 6, and Oracle Application Server 10g offer numerous tuning features.
• Thread pools. Again JBoss 4, BEA WebLogic 9.2, IBM WebSphere 6, and Oracle Application Server 10g offer a lot of options.
• JVM settings. The default heap size can be as low as 64MB! Next to the standard JVM options, the Sun JVM, IBM JVM, and the BEA JRockit JVM have their own sets of specific options. Of particular interest to people using the Sun JVM is Joseph D. Mocker's list of JVM options, a comprehensive collection of options sometimes only mentioned in bug reports and other obscure places.

Next to these specific tips, BEA WebLogic 9.2, IBM WebSphere 6, and Oracle Application Server 10g have performance tuning guides. For JBoss a number of forums are available, as well as an unofficial JBoss performance tuning guide.

Filed under Java, Performance | 2 Comments »