Previous    Next

The Primary Causes of Performance and Scalability Problems in J2EE apps

We've discussed all these points previously, but the following is a quick summary, in no particular order, of what I've found to be the primary causes of performance and scalability problems in J2EE apps I've seen.

• Wrongly configured JVMs, app servers, or databases.

• Using a distributed architecture when it's inappropriate. Remote invocation is one of the most expensive operations an app can perform.
• Unnecessarily "chatty" invocation of EJBs in distributed apps.
• Use of EJB without good reason in collocated apps. Unless using EJB adds real value, it simply adds complexity and significant run-time overhead.
• Using stateful session EJBs when stateless session EJBs could achieve the same task.
• Poor performance in a cluster and reduced scalability due to failure to consider the implications of state management. For example: holding unnecessarily large amounts of session state for each user; failure to remove inactive sessions.
• Use of entity EJBs with BMP, where large result sets must be returned from finder methods.
• Use of entity EJBs at all in situations where O/R modeling is inappropriate and JDBC would prove much more efficient. As I noted in , J2EE developers tend to be rather doctrinaire about data access; efficiency seems to be prioritized well below the theoretical ideal of a "pure" J2EE architecture.
• Use of entity EJBs with remote interfaces. With the introduction of local interfaces in EJB 2.0, this can simply be viewed as a design mistake.
• Failure to leverage the capabilities of the target database. In this common scenario, developers concentrate on code portability, when it's better to concentrate on design portability, hiding efficient use of performant idioms behind a portable interface. For example, blanket rejection of the use of stored procedures may result in needlessly slow RDBMS access.
• Blind faith in some "J2EE design patterns" which lead to poor performance. In we discussed the performance controversy over Sun's Java Pet Store sample app, which demonstrates this danger.
• Failure to cache resources and data that should have been cached: for example, performing needless JNDI lookups or repeated database access to retrieve reference data.

Previous    Next