Java Reference
In-Depth Information
Assume eventual parallel deployment.
In designing for scalability, it's
much easier to plan for eventual parallel deployment in advance, even
if the added scalability is never needed. Even if you don't initially
deploy on a parallel architecture, it pays to keep that option open for
the long term. That means addressing the following:
Database designs should assume shared access with reliable concur-
rency control.
Session state should be deployable across multiple machines, with a
strategy for ensuring session affinity or keeping track of a multipart
conversation in a parallel architecture.
Operating system services and other services should be deployable in
a parallel configuration.
The model should have a clear path to a sharable, scalable solution.
4
Tackle high-risk elements first.
With all projects, risk mitigation
involves planning for the worst possible contingency. That means
addressing high-risk elements as early as possible in the development
cycle, with sufficient time to recover.
5
Perform a sanity check on key assumptions as needed.
While a full-blown
performance test belongs at the end of the cycle, frequent sanity
checks of critical risk elements are a good idea. Identify these key risk
elements in the performance plan. System architects need to under-
stand what elements are likely to break.
6
Plan for contingencies.
Internet workloads are inherently unpredict-
able, and aggressive contingency plans should mitigate that risk. Make
contingency plans for any highly performance-sensitive components
with completion dates scheduled later in the development cycle. Risk
mitigation can often provide for a delayed delivery of a subset of sensi-
tive components in order to protect the whole application. All stake-
holders should sign off on aggressive schedules.
7
Plan to test the system and key touch points.
Several tools can help you
test parallel architectures under load with enough time to recover.
Many Internet applications enable access to legacy systems. These sys-
tems were frequently not designed for the type of access or the scale
that the enabling technologies provide. Testing the
back end
in the
new context is critical; ensure that you have enough time to adjust for
any problems.
8
