The Load Model
With performance testing we try to predict the performance of an application. Either through load and stress testing or model driven performance testing. The idea is that you want to spot the performance problems before the application goes live and solve them before it hurts. Predicting the application performance means various things including predicting the capacity-need. For this you need to have any idea of how much use is going to be made from the application. This comes down to estimating or predicting that usage. In fact you try to predict the capacity-need in two steps: 1) predict the usage of the application 2) predict the capacity need for that particular usage. The output of the process of predicting the usage is the Load Model. In the pre-deployment stages this process is not trivial and several stakeholders may be involved. There is literature on this subject under the heading “Workload characterisation”.
Here are some ideas for a practical approach that one may apply as soon as all transactions of the application under test have completed.
First you may have a look at the context of the application and observe if you have a corporate, business to business (b2b), or a business to consumer (b2c) application on your hands. A corporate application has an overseeable (I write English, you learn Dutch) number of users, limited by the number of staff in the company. A b2c application has 7 billion potential users and you hope that they are not going to use your application all at the same time before you applied the necessary preparations. Nobody can give any guarantee. Speaking about warranties, the business is responsible for the main input of the load model, but nevertheless they often will hold you accountable no matter how poor their figures were if this turns out to be inaccurate.
There are two possible tracks for creating the Load Model.
- On the basis of the transaction volume
Apply a structure of use cases and transactions. Consult business analysts and software developers. Determine transactions per second for the blend.
- On the basis of concurrent users
This requires determining the think times. Think times are the times between the transactions as the sum of two parts: the time it takes the user to read the output from the previous transaction and the time it takes to prepare firing the next transaction. You can get fairly accurate estimates by manually executing the transactions while visualising the users position.
Through Little’s formula you can derive one from the other.
I published an article about this subject with a detailed example, in the series “Applying performance modelling”, which you can download from our website.
www.mbrace.nl/uploads/images/Articles/Article%202%20-%20Usage%20Volume.pdf
Whether you try to secure application performance through load and stress testing or performance modelling makes no difference, you need an accurate Load Model anyway, because you cannot produce a reliable result without it!! You should be able to say: "I tested the performance of this application at this particular usage".