The reasons for investigating performance are to answer questions that you
may have about a current or proposed site. These questions are varied, and are
likely to include some of the following:
How can we best speed up our site? i.e. where are the greatest time and
resources being used? Also, where should development time be best spent?
How loaded is the system? In particular, how close is the system to saturation?
i.e. when are we likely to run out of processing power and/or memory?
Will the system be able to cope
- if we have a promotion?
- during the Christmas rush or before valentines day?
- when we release a new product?
How does our system compare with the competition?
Will our new architecture be able to cope with projected usage?
How quickly does/will our system respond to users?
How will the system response time vary by the method of access - e.g. broadband,
modem, WAP?
What happens when the system reaches saturation?
Is the system performing as expected? e.g. are there any parts of the system
that are configured incorrectly?
Can we reduce the initial system cost by reducing the initial hardware requirements?
e.g. can we delay the purchase of some of the servers until usage increases?
In addition to providing answers to the above and your own specific questions,
an independent performance investigation offers many other benefits, including:
specialist knowledge, experience and understanding of performance issues
a vital independent second opinion
an extra resource for identifying system problems
identification of metrics for measuring system attributes, e.g. to determine
when a system is nearing the limits of its processing/memory capacity
When can a performance investigation take
place?
Performance can be investigated at every stage of the development cycle, but
the type of investigation will vary, some of the most likely investigations
are:
Before design: Performance focused architecture design and performance
experiments. During design: Performance prediction to validate the design. During build: Prediction to validate the design and focus resources. After build: Prediction and testing to discover areas of concern. During testing: Performance testing and optimisation to check for system
load and response times and to improve them as needed. After delivery: Performance testing to check system load and to warn
when the system nears the end of its useful life. Performance optimisation
to keep a system useful for longer.
When is a performance investigation worthwhile?
Performance investigations bring the best results when one or more of the following
apply:
There are a large number of user accesses to the site.
There is a large data set.
There is strong security in place.
Each user accesses the system frequently.
The system is used internationally.
There can be a sudden increase in use.
A large amount of data is returned.
The current system response time is too slow.
The current system is overloaded.
If several of the above factors apply, then the risk of a system failing to
meet the performance requirements is high and a performance investigation can
reduce the risk greatly.
