Java Reference
In-Depth Information
Internet workloads can be inherently unpredictable.
If the target audi-
ence of an Internet application is not well defined, it's easy to underes-
timate the size of the community. At the height of the dotcom boom,
technology companies dealt with workload prediction in different
ways. Some hardware companies installed additional servers, free of
charge, and allowed their clients to pay only when the servers were
turned on. Designing for unpredictable performance can be a dicey
proposition. It's tough to decide whether a constrained budget should
focus on additional hardware or high-priority software features. This
unpredictability, combined with the lack of a realistic performance
plan, can throw off initial estimates considerably.
Some platform-dependent architectures can be difficult to scale and adapt
to common Internet architectures.
Taking an early shortcut to build in a
convenient platform-dependent feature can result in impaired scalability
down the road. If the performance requirements aren't clearly commu-
nicated, this trap is much more likely to appear.
By failing to take performance into account, a company can underesti-
mate hardware needs or development time.
Robust, scalable architectures
take money and time. Without a clear understanding of what is neces-
sary, under-budgeting is a real danger.
The most common highly scalable architectures require a number of
assumptions about architecture and design.
Following a set of conven-
tions for building highly parallel systems is much easier at the front of
the development cycle. Decisions about session state management, per-
sistence, locking, multithreading, loose or tight coupling, programming
language, and dynamic content management will have a bearing on how
a massively parallel architecture is built. Poor decisions on any of those
fronts will limit the options available for creating parallel architectures
.
10.2.2
Some real-world examples
Let's look at some real-world examples of companies that failed to adequately
plan for performance. As a member of a database critical-situation manage-
ment team and later as a consultant, I've dealt with many failures involving
scalability. (Of course, I'll maintain the confidentiality of my customers for
obvious reasons.)
Late performance design
Early in 2001, a large travel company implemented an
EJB
solution from the
beginning. The architecture had many different complex layers and aggressive
