Java EE 5 Performance Management and Optimization

“Okay, I understand how to gather metrics, but now what do I do with them?” John asked,
looking confounded. “If I have application response time, instrumentation, and application
server metrics, what should I have my developers do to ensure that the next deployment will be
successful?”

“That is a very good question. At its core, it involves a change of mind-set by your entire
development organization, geared toward performance. Youll most likely feel resistance from
your developers, but if they follow these steps and embrace performance testing from the outset,
then youll better your chances of success more than a hundredfold,” I said.

“I can deal with upset developers,” John responded. “The important thing is that the application
meets performance criteria when it goes live. Ill make sure that they follow the proper
testing procedures; they have to understand the importance of application performance. I just
cant face the idea of calling the CEO and telling him that we failed again!”

“Dont worry, Ive helped several customers implement this methodology into their development
life cycle, and each one has been successful. It is a discipline that, once adopted, becomes
second nature. The key is to get started now!”

“Tell me more,” John stated calmly, in contrast with his stressed demeanor. I knew that
John had seen the light and was destined for success in the future.

Performance Overview

All too often in application development, performance is an afterthought. I once worked for a
company that fully embraced the Rational Unified Process (RUP) but took it to an extreme. The
application the company built spent years in architecture, and the first of ten iterations took
nearly nine months to complete. The company learned much through its efforts and became
increasingly efficient in subsequent iterations, but one thing that the organization did not
learn until very late in the game was the importance of application performance. In the last
couple of iterations, it started implementing performance testing and learned that part of the
core architecture was flawedspecifically, the data model needed to be rearchitected. Because
object models are built on top of data models, the object model also had to change. In addition,
all components that interact with the object model had to change, and so on. Finally, the application
had to go through another lengthy QA cycle that uncovered new bugs as well as the
reemergence of former bugs.

That company learned the hard way that the later in the development life cycle performance
issues are identified, the more expensive they are to fix. Figure 1 illustrates this idea graphically. You can see that a performance issue identified during the applications development is inexpensive to fix, but one found later can cause the
cost to balloon. Thus, you must ensure the performance of your application from the early
stages of its architecture and test it at each milestone to preserve your efforts.

Figure 1. The relationship between the time taken to identify performance issues and the
repair costs

A common theme has emerged from those customer sites I visit in which few or no performance
issues are identified: these customers kept in mind the performance of the application
when designing the application architecture. At these engagements, the root causes of most of
the application problems were related to load or application server configurationthe applications
had very few problems.

This is the first in a series of three articles that formalizes the methodology you should implement to ensure the performance
of your application at each stage of the application development, QA, and deployment stages.
I have helped customers implement this methodology into their organizations and roll out
their applications to production successfully.

Performance in Architecture

The first step in developing any application of consequence is to perform an architectural analysis
of a business problem domain. To review, application business owners work with application
technical owners to define the requirements of the system. Application business owners are
responsible for ensuring that when the application is complete it meets the needs of the end
users, while application technical owners are responsible for determining the feasibility of
options and defining the best architecture to solve the business needs. Together, these two
groups design the functionality of the application.

In most organizations, the architecture discussions end at this analysis stage; the next step
is usually the design of the actual solution. And this stage is where the architectural process
needs to be revolutionized. Specifically, these groups need to define intelligent SLAs for each
use case, they need to define the life cycles of major objects, and they need to address requirements
for sessions.