Vincent Partington has written a series of short articles, each article focusing on one potential Java EE application performance problem. In a concluding article, EJAPP Top 10 countdown wrap-up, he shares a few bits of parting advice. Noting that most performance problems arise because of incorrect use of technologies, mostly due to developers not fully understanding how to use a technology, Partington writes that,

Java developers should consider performance an important quality requirement of their application to which they should pay attention from the start to the end of the project... Java developers need to work with the people that can help them improve the performance of their application like application server and database administrators...

Partington covers the following performance-related topics in his series:

10. Excessive logging
Two things happen when you log. First a number of String manipulations are performed ... and then the resulting String is written to a file...

9. Incorrect application server configuration
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“... Developers should not just throw their EAR file over the wall; developers and application server administrators need to work together on this...

8. Incorrect usage of Java EE
This problem is particularly prevalent in older applications that were developed before the POJO/lightweight revolution a few years back... Lightweight frameworks like Spring allow the developer to pick and choose the infrastructure services (transactions, security, distributed objects) that are needed. Java EE... offers all of them all of the time.

7. Unnecessary use of XML
XML has a number of interesting properties that cause it to be used for a whole range of functions in the average Enterprise Java application... Unfortunately XML processing is heavy on CPU cycles and on memory usage.

6. Improper caching
Done right it can improve the performance of your Enterprise Java application tremendously and can even be essential to reach acceptable performance levels, but sometimes caching itself can be the cause for your performance problems.

5. Excessive memory usage
Excessive memory usage manifests itself in two ways: a large number of allocations (for short-lived objects), or a large number of objects per se.

4. Badly performing libraries
Some development teams will happily pile JAR after JAR into their WEB-INF/lib directory or into their POM file without checking whether that library is really needed (and does not overlap with functionality already offered by other libraries used), without checking whether that library can offer good performance or whether a better performing alternative is available, without reading the documentation to see how it should properly be used, and without defining how the library is going to be used within the application.

3. Incorrectly implemented concurrency
A major cause is lock contention, which only becomes an issue when multiple threads are involved... Applications that perform pretty well under light load may crawl to a halt under heavier load...

2. Unnecessary remoting
In some cases an architecture is designed with remoting built-in for some anticipated future need that never occurs... While remoting is often used in Enterprise Java applications due to the fact that other systems and applications need to be invoked, unnecessary remoting is an important cause of badly performing Enterprise Java applications...

1. Incorrect database usage
In a lot of Enterprise Java projects, the database is treated as a simple bit bucket and the DBA as just the guy that executes the SQL statements on the production machines. This disdain for the database and its experts leads to badly performing applications...

What's the source of your #1 enterprise Java performance problem?