What can wreck the performance of your J2EE applications?

Performance measurement and application profiling are usually put off until problems turn up. Then developers have a few anxious moments as they work out what they got wrong, where they got it wrong, and how it affected application performance. In theory, the first rule of optimization says “don’t optimize,” but in practice that can get expensive.

In my experience, you can eliminate most application performance problems before deployment to production. The rule I put ahead of “don’t optimize” is to prevent problems by knowing your enemy. Most performance problems come from not understanding a technology and using it incorrectly as a result. Take your pick of technologies, from JDBC to EJB to Hibernate.

Every enterprise application technology has performance pitfalls. A little preventive work within the team can avert the worst of them at almost no cost. Load tests are fairly reliable at finding a second set of performance issues. One example is synchronization hidden at first glance, such as in a third-party API, which reduces how much work can be done in parallel. See Amdahl’s law.

Speaking of knowing your enemy, you may find these ten areas of performance problems useful. Vincent Partington gathered and investigated them.

• #10 — Excessive logging
• #9 — Incorrect application server configuration
• #8 — Incorrect usage of Java EE
• #7 — Unnecessary use of XML
• #6 — Improper caching
• #5 — Excessive memory usage
• #4 — Badly performing libraries
• #3 — Incorrectly implemented concurrency
• #2 — Unnecessary remoting
• #1 — Incorrect database usage

The funny thing is that every developer has these ten areas somewhere in the back of their mind, yet tends to forget them, just as they forget prevention and performance testing…

Related links

• TSS — Vincent Partington: Top 10 Java EE performance problems
• Java Performance Tuning
• Java 6 — Where the Speedup Comes From (synchronization optimizations)