Expert One-on-One™ J2EE™ Development without EJB™

Chapter 15. Performance and Scalability

Performance and scalability often determine the success or failure of enterprise applications.

A surprisingly large proportion of J2EE applications encounter performance problems: often too late in the project lifecycle for them to be solved cost effectively, leading to the risk of complete failure.

It's not that J2EE is inherently slow. It's that inherently slow architectural patterns are undeservedly popular, and far too many J2EE architects have a blind spot regarding performance. Despite the ample evidence that performance risks should be considered early in the project lifecycle, they believe that performance can safely be addressed after an application is functionally complete, usually through:

• Code optimization; or

• More, or faster, hardware—often seen as a panacea

Both of these assumptions are wrong. Code optimization often amounts to moving the deckchairs on the Titanic. Architecture, not implementation, usually determines performance, and optimizing code will seldom radically change performance characteristics. (However, code optimization is an excellent way of reducing maintainability and increasing the potential for bugs.) Even if applying more hardware solves a throughput problem—which it often doesn't—it often amounts to a waste of money, when the application requires far greater hardware resources than it should.

The blind spot often extends to a belief that a "pure" architecture is more important than a performant application. This ...