email article printer friendly

Architecture Is Key to Optimization
Vendors jockey to deliver the means for developing J2EE app development performance processes
by Peter Varhol

September 2003 Issue

Performance used to be easy, or at least manageable. If you understood the performance implications of different language constructs, you could write your code with the best algorithms and the most efficient SQL, touching the minimum amount of data the minimum number of times, and end up with the fastest application. When most computation is executed within a single process on a single computer, optimizing the computation within that process was good enough to optimize the application.

Distributed applications and Java 2 Platform, Enterprise Edition (J2EE) changed all that. It's not about getting each process to run well. You can do that all day, and at the end of the day still have a poorly performing application. Yet we persist in tuning individual code segments in components that may not be the critical path of a transaction through the system, because that's what we know how to do. And there's few methodologies or development tools that let you pinpoint bottlenecks and tune an entire distributed application.

A well-known example of the issues in tuning code is the Java Pet Store application, written by Sun to demonstrate the use of best practices, design patterns, and architectural ideas for J2EE applications. To best illustrate many of these concepts, the authors used generic data source connectors and other structures that could be mapped to any of several databases, hardware, and operating systems. It was built so that its components could be useful broadly across platforms and databases.

Nobody had ever claimed that the Java Pet Store was a benchmark, yet it has become the center of the controversy between the .Net and Java platforms and symbolic of the larger issue of how to optimize an application that served too many purposes. Microsoft's .Net implementation of the Java Pet Store, written for the SQL Server database running on Windows servers, easily outperformed the Java version. There are many lessons to be learned from this comparison, not the least of which is that your nonfunctional design goals can significantly influence application performance.

As an academic teaching novice computer science students in the 1990s, I had frequently used Robert Heinlein's inspired acronym TANSTAAFL—for "there ain't no such thing as a free lunch"—to impress upon them the fundamental trade-offs of application construction. This phrase summarizes succinctly the fact that when you optimize for performance, you give up something else. In the case of the Java Pet Store controversy, Microsoft traded off the flexibility to work with different components to implement an optimized version. The key to writing a successful application is to understand both the functional and the nonfunctional requirements and to optimize based on the trade-offs between these requirements.