Java Reference
In-Depth Information
10.7
T
aming the performance beast
In this chapter, we discussed performance antipatterns. Some were related to
code, but most were related to process. The unpredictable growth and work-
loads inherent in high-volume Internet applications make achieving good per-
formance tuning more difficult. Planning and testing are mandatory, leaving
enough time at the end of the cycle to tune the system to predefined specifica-
tions. Many Internet architects are turning to parallel architectures to provide
scalability, with a dispatcher serving multiple web servers, which in turn serve
multiple web application servers. The complexity of these solutions makes the
architectures ripe for antipatterns. We should pay special attention to even
workload distribution, round-tripping across interface boundaries, and session
state management. A world-class performance-testing environment, built or
rented, and a solid performance-testing methodology are critical.
10.8
Antipatterns in this chapter
These are the templates for the antipatterns that appear in this chapter. They
provide an excellent summary format and form the basis of the cross-refer-
ences in appendix A.
Performance Afterthoughts
D
ESCRIPTION
:
Poorly defined performance plans, poor requirement spec-
ification, and inattention to performance throughout the cycle can lead to
nasty surprises at the end of the cycle.
M
OST
FREQUENT
SCALE
:
Application.
R
EFACTORED
SOLUTION
NAME
:
Performance Planning.
R
EFACTORED
SOLUTION
TYPE
:
Process.
R
EFACTORED
SOLUTION
DESCRIPTION
:
Gather performance require-
ments, plan, and prepare for the future. Sanity-check key components,
and address the riskiest elements of the architecture early.
T
YPICAL
CAUSES
:
Poor planning.
A
NECDOTAL
EVIDENCE
:
“We'll have plenty of time to performance-tune
at the end of the cycle.” “It is a good design. We don't need to tune for
performance.” “We'll let our unit testers probe for performance.” “We've
done all of our test cases except our performance test case.”
