Often, Performance testing is
said to be Art + Science. And the major
part of this ‘Art’ lies in designing workload model for the application or
product under test.
What is Workload ?
To put it simply, Workload is
nothing but amount of work the system must do in given period of time. In the
context of performance testing, its about understanding what sort of load
system will be catering in production.
Factors deciding workload
So to define workload, need
to decide upon below factor:
1.
No. of concurrent
Users/sessions
2.
User profiles
3.
Mix Use
cases/Business processes/operations
4.
Throughput i.e. no
of operations or transactions done during load [Transactions per Hour]
5.
SLAs – in terms
of Throughput , response times & resource utilization
Steps to Design Workload
Model
1.
Predicting
application usage for future : Major
part of it should be deciding upon the flows/business processes to be tested,
their implementation & navigation paths.
2.
Obtaining Volumes:
Need to obtain details of ‘maximum no. of concurrent users’, ‘Mix of business
processes’ & ‘maximum no. of transactions/operations predicted.
e.g. lets
say we will have 100 as maximum no. of concurrent user operating , majorly
doing 5 flows/business processes & during peak hour maximum operations done
are 10000.
If the business
process mix is: 10%, 20%, 30%, 15%, 15%. Then using this info, we derive below
statistics:
Business Process/Use Case
|
No of concurrent Users
|
No of operations/transactions to be done during peak
hour
|
Case 1
|
10
|
1000
|
Case 2
|
20
|
2000
|
Case 3
|
30
|
3000
|
Case 4
|
15
|
1500
|
Case 5
|
15
|
1500
|
Total
|
100
|
10000
|
This is
simplistic case given for explanation. In reality, percentage of no. of users
mapped and no of operations could be different. It depends upon type of user
profiles & its usage.
3.
So , we have no
of councurrent users & no. of
operations to be performed per use case. In order to design our tests , need to
decide upon pacing & think time. Alternative way is to use – ‘goal oriented
scenario’ in Loadrunner Or ‘constant throughput’ timer in
Jmeter.
In order to
decide upon it manually, one should know baseline results for particular flow –
how much time a business process takes to complete without think time.
e.g. lets
say case 1 takes 30 seconds to complete
without think time & has 3 think time statements in side script. Lets say
if keep think time value to ~10 seconds then with think time , it will need 30
+ 30 = 60 seconds for one iteration. And here in our case each user has to
perform 1000/10 = 100 iterations in hour.
So with
current think time & without pacing , each vuser will do 3600/60 = 60
iterations per hour. In order to target 100 iterations , each iteration should complete in 3600/100 = 36 seconds. So if we
set 2 seconds as think time , then we will have these targets achieved – 30 +
(3*2) = 36 seconds.
Its quite
common for an application to cater different workloads at different point of
time in a day or as per business milestones. Different workload models to
should be designed & tests should be carried out to see impact on
application performance.
No comments:
Post a Comment