Java Reference
In-Depth Information
performance criteria. Though significant elements of the design were com-
pleted very early in the project, the first performance benchmark was not run
until weeks before the project was scheduled to be completed. When the
project was near completion, a performance snapshot revealed significant
problems with production data volumes and workload. By that time, pro-
jected changes to the base object model and framework forced the team to
scrap the
EJB
architecture, because not enough money was available to handle
the extensive revisions. The project changed direction to use simple screen
scraping front ends from 20-year-old technology. In a postmortem, the team
agreed that an early-performance sanity check would have caught the problem
in plenty of time.
No planning
In 2000, a small company built a complex user interface. The business analysts
established few hard performance requirements, and they neglected to create a
comprehensive performance plan. To complicate matters, no time was left at
the end of the cycle to handle performance testing. In order to compensate,
the programming team asked the entire company—board members and ven-
ture capitalists included—to assist in a companywide “test fest.” This high-vis-
ibility event was the first time that the system was tested under load. It failed
in several different ways; for example, a single JavaScript custom control took
several minutes to populate. The company has since laid off more than two-
thirds of its staff and is struggling to stay afloat.
Insufficient funds
In 1998, a large Fortune 100 energy company decided to release a company-
wide intranet infrastructure. The performance requirements were rigorous
and stringent. The development team finished three major risky components
early in the cycle, but they did not test the components under load. One of
the components was a custom persistence framework. It failed, because many
functions that would otherwise be handled by relational joins and low-level
database functions were instead handled by the application. The alternatives
radically changed the underlying persistence framework as well as the object
model on top of it. The company completed the project only after significant
schedule delays, penalties, and cost overruns that ran well into seven figures.
10.2.3
Solution: Plan for performance!
My early trip down the Chatooga reminds me of high-volume Internet appli-
cations. Scalability is one of the most technically demanding characteristics to
