Workload Models

Increasing – At the beginning of a load test, Silk Performer does not simulate the total number of users defined. Instead, it simulates only a specified part of them. Step by step, the workload increases until all the users specified in the user list are running.

This workload model is especially useful when you want to find out at which load level your system crashes or does not respond within acceptable response times or error thresholds.

Steady State – In this model, the same number of virtual users is employed throughout the test. Every virtual user executes the transactions defined in the load-testing script. When work is finished, the virtual user starts again with executing the transactions. No delay occurs between transactions, and the test completes when the specified simulation time is reached.

This workload model is especially useful when you want to find out about the behavior of your tested system at a specific load level.

Dynamic – You can manually change the number of virtual users in the test while it runs. After the maximum number of virtual users is set, the number can be increased or decreased within this limit at any time during the test. No simulation time is specified. You must finish the test manually.

This workload model is especially useful when you want to experiment with different load levels and to have the control over the load level during a load test.

All Day – This workload model allows you to define the distribution of your load in a flexible manner. You can assign different numbers of virtual users to any interval of the load test, and each user type can use a different load distribution. Therefore, you can design complex workload scenarios, such as workday workloads and weekly workloads. You can also adjust the load level during a load test for intervals that have not started executing.

This workload model is especially useful when you want to model complex, long lasting workload scenarios in the most realistic way possible.

Queuing – In this model, transactions are scheduled by following a prescribed arrival rate. This rate is a random value based on an average interval that is calculated from the simulation time and the number of transactions per user specified in dcluser section of your script. The load test finishes when all of the virtual users have completed their prescribed tasks.

Note: With this model, tests may take longer than the specified simulation time because of the randomized arrival rates. For example, if you specify a simulation time of 3,000 seconds and want to execute 100 transactions, then you observe an average transaction arrival rate of 30 seconds.

This workload model is especially useful when you want to simulate workloads that use queuing mechanisms to handle multiple concurrent requests. Typically, application servers like servlet engines or transaction servers, which are receiving their requests from Web servers and not from end users, can be accurately tested by using the queuing model.

Verification – A verification test run is especially useful when combined with the extended verification functionality. This combination can then be used for regression tests of Web-based applications. A verification test performs a specified number of runs for a specific user type.

This workload is especially useful when you want to automate the verification of Web applications and when you want to start the verification test from the command line interface.