Wednesday, April 13, 2016

Performance Workload Modelling



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