IDE & Navigation
Properties & Tools
Load testing is performed using the existing models. The process is quite simple. We will describe these steps in this document.
The first step in load testing is to determine the type of loads and how much you wish to exercise on AUT. Typically you would already have suite of models created for functional testing of AUT. These models when executed generates a specific type of loads on AUT.
Carefully select a subset of these models that will generate the type of loads required and determine the number of virtual users for each selected models. You may use the following table to help you plan your next load testing:
Model Name Users Traversal Delay (sec) Repeat Delay (sec) Bad Login Attempt 20 10 3000 Casual Browsing 300 5 30 Quick Purchase 100 5 30 MultiItem Purchase 200 8 20 Add/Remove Items 150 15 30 Cancel Order 50 10 120
The Traversal Delays (in seconds) is sort of user think time, time delay between key clicks.
Repeat Delays (in seconds) is the time delay between successive execution of the same model by the same virtual user (thread).
With the load table filled (above), you can then set up the environment and servers for load testing. Set up one Runtime server for each model and deploy the model to the server by copying model folder to each Runtime server. Open the model on Runtime server and set the virtual user (thread) count, traversal delay and repeat delay per load testing table above. See below:
It is recommended to limit the number of virtual users per Runtime server in order to achieve reasonable performance by spreading virtual users among multiple Runtime servers (additional Runtime license required).
Select the appropriate sequencer and set appropriate stop criteria for each model.
Execute the model on each server and monitor the model executions to ensure all models are executing with the right number of virtual users (threads). Adjust the execution setting if necessary during execution. See example monitor tab:
When the load testing is completed, review and analyze the performance stats shown in MonitorTab from all servers. If desired, you may want to save and publish the stats for future review.
Below are a few things to consider:
To be able to simulate large number of concurrent users running scenarios through execution of different models as set up above, you may need to use more than one Runtime Servers. Server Manager (SvrMgr) can manage all of the Runtime Servers effectively. It not only manages the start and stop of Runtime Servers, most importantly it also deploys (pushes) models to all Runtime Servers.
With Enterprise Edition, you can also create a model to orchestrate the execution of different models to simulate the exact load you need on AUT.