Performance Testing - Software Testing: Testing Across the Entire Software Development Life Cycle - page 132

Peak usage is normally measured in terms of active users. For example, if 500 users
normally log on to the purchasing system over the lunch hour and 2,000 users nor-
mally log on around 7 P . M . in the evening, then the peak expected workload for all log
on/log off is 2,000 users. Notice also that the peak expected workload is 2,000 users
whether the user base is 2,000 users or 2,000,000 users.
When researching the peak workload of users for a particular group of transactions,
specify that you are interested in numbers of active users at peak workload time rather
than the number of concurrent users. Concurrent user workloads are of interest for
specifi c tests such as database record lock contention, deadly embraces, or network
packet collisions. The actual occurrence of truly concurrent activity is rare. For ex-
ample, if the peak workload is 2,000 active users, then it will be most unusual to ob-
serve more than fi ve truly concurrent users at any time. Truly, concurrent users press
the Enter key on the same transaction at precisely the same time causing the same
transaction to launch in the application and follow exactly the same execution path.
Active users access the system during the same timeframe, have been allocated
system resources for a work session, and are launching a variety of activities or
transactions based on their job role or customer needs. It is this allocation/realloca-
tion of system resources during the active work sessions that will affect the vast
majority of transactions being launched. Each launched transaction will compete
with every other launched transaction for these fi nite system resources. It will be the
objective of the performance instrumentation to measure how well the transactions
compete for these resources under different workload situations.
The peak usage of each transaction group is now added to the workload plan:

Draft 2 Performance workload plan

Response time
requirement

Peak active
users/
customers

Day/time of peak
activity

Transaction group

Menu navigation
Log on/Log off
Product detail display
Purchase steps
Catalog search
Credit card payment

Max 3 seconds
Max 3 seconds
Max 4 seconds
Max 7 seconds
Max 10 seconds
Max 30 seconds

2,000
2,000
2,000
500
2,000
500

Mon-Fri 12-1 P . M .
Mon-Fri 12-1 P . M .
Mon-Fri 12-1 P . M .
Sat 9-11 A . M .
Mon-Fri 12-1 P . M .
Sat 9-11 A . M .

The Mon-Fri 12-1 P . M . peak activity entry means that a peak of 2,000 custom-
ers use the system during lunchtime at least one workday of the week. From a per-
formance testing perspective, it does not matter which specifi c day it occurs or if it
occurs during several weekdays. The peak is the peak from a performance testing
perspective. Later in the development process, the production staff will want very
much to know which day(s) of the week the peak occurs for production schedule
perspective.
The third performance tester's challenge is to clarify just how many different
workload peaks need to be tested. Looking down the Draft 2 plan, you will notice