Java Reference
In-Depth Information
This was not an isolated case. Out of an estimated 50 customers I visited
during that period, only four had reliable performance-testing plans.
Ten years later, I am consulting. The problem domain is dramatically dif-
ferent. Performance analysis is one of very few areas that have become more
complex with Internet deployment. For public deployments, the size of the
user community for a given application generally cannot be determined in
advance. The networks leading to the application servers are rarely under the
sole control of the information technology staff. It's much more difficult to
educate users about practices that are likely to stress a system. At the same
time, for most companies performance- and stress-testing techniques have
changed very little.
At allmystuff, we had very strong technical leadership but did very little
performance testing. If we'd encountered significant success—and the ensuing
traffic—I'm not sure that our architectures could have handled the load.
Though our network topology was solid, our design model captured every
object as a persistent
EJB
, and we did no dynamic caching. Our quality assur-
ance department had tests for fail-over, but performed very limited tests for
heavy concurrent use. Because our product never attracted enough customers
to stress the system, we failed long before we were forced to pay for our
errors. As a consultant, I find that my clients usually haven't performance-
tested their applications, or they've been blindsided by the high number of
users in their systems. This situation is normal, but it represents a very danger-
ous way of doing business. Sometimes, systems are designed well enough to
scale as user needs grow. Other times, they are adequate to handle the needs
of the initial community, but when the user base increases unexpectedly, scal-
ability problems are uncovered. As with many relatively new technologies, per-
formance problems mar Internet deployments all too often.
10.2.1
Developing without performance planning
The Performance Afterthought antipattern is process oriented. In general,
architects focus on business and end-user requirements at the front of the
cycle and give only marginal attention to performance considerations. Perfor-
mance decisions are saved for the end of the cycle. In the Internet environ-
ment, this strategy can be fatal for a variety of reasons, as the following shows.
Considerations for early performance planning on Internet projects
For Internet applications, performance cannot be treated as an afterthought without
dire consequences. Here are some factors that complicate delayed planning, coding,
and testing of performance components of a system:
