Information Technology Reference
In-Depth Information
that introduces increasingly more workload of increasingly more complex business
transaction mixes.
9.2 WORKLOAD PLANNING TECHNIQUES
Yo u r fi rst thoughts about performance testing may revolve around timing
measurement precision. If the workload is incorrectly planned or executed, the most
precise timing measurements will not bear any resemblance to the timing exhibited
by the software in production. So we need to consider workload planning as the fi rst
step in performance testing.
The performance tester's fi rst workload challenge is to identify which business
transactions and activities need to be measured for performance. In all but the simplest
software applications, it is diffi cult to identify the most important transaction and activ-
ity candidates for performance testing. The diffi culty lies partly with the software end
user's typical reaction, “everything must respond in less than 3 seconds.” Somehow the
tester must convince the end-user that different groups of transactions and activities
will have different performance requirements based on different business priorities.
For example, customer purchase transactions may need to be completed in less
than 3 seconds in order to keep the customer interested in buying more merchandise.
By contrast, the transactions like credit card validation or warehouse ship ordering
that occur to complete the purchase can be done 3 hours later and the customer will
still get his or her merchandise delivered on the same date next week. This slow re-
sponse time grouping may not thrill the employees, but as long as they can get their
job done in time, the business investment required to speed up the employee transac-
tion grouping response time faster than 3 hours has a very low return on investment.
Another example would be bank customer online requests for fund transfers.
Because it is the policy of most banks to make the fund transfer available no sooner
than overnight, the online customer request confi rmation for fund transfer may have
a 5 seconds response time requirement whereas the transfer transaction itself has a
12 hours response time (batch, overnight).
Lurking in the background of all online transaction rate discussions is the “Rule
of 8.” The Rule of 8 is a human behavior discovered in the 1970s by measuring the
productivity of computer users as their system response time slows from subseconds
to 20 seconds. The conclusion back in the 1970s and reconfi rmed in the 1990s is that
when the system response slows down beyond 8 seconds per transaction, human pro-
ductivity falls off dramatically. The popularly accepted explanation for this phenome-
non is that when the system responds in 8 seconds or less, the computer user can retain
his or her train of thought about intended next actions. Response times longer than
8 seconds cause the computer user to forget what he or she was doing or intended to do
next. For this reason, there was much emphasis placed on response times of 8 seconds
or less for mainframe and client/server applications during the 1980s and 1990s.
Her e is a n i nt er est i ng side not e to t he Ru le of 8. Comput er c ent er st a f f cont i nu a l ly
need to manage the expectations of their users. If something does not work correctly,
the users get upset. If something does not work fast enough, the users get upset. By
Search WWH ::




Custom Search