GeekLoad works according to the concept of Project as code. The entire configuration of the project is determined by the script.
You can take all the power of script code and make your tests as flexible as needed. Scripts give one more benefit: you have all definitions – load profiles and tests – in a simple text format. When you push changes to a source control, you can easily see what has been changed. This would be impossible if we used binary formats.
GeekEngine turns JavaScript into a distributed load testing language without violating its syntactic rules.
GeekLoad’s projects are one or more JavaScript files. You can start with just one file, and have all load profile definitions, test requests and checkpoints in a single place. As you progress, you can split your code into several files and import them into each other. And of course, you can continue using just one file, if you want. We’re not going to limit geeks :-).
Although the script on which GeekLoad projects are made is pure JavaScript, to run these projects you need to use only GeekLoad, but not NodeJS or a similar engine.We introduced this restriction in order to have full control over the execution of tests and add features not available to the regular Javascript engine.
Each project must contain the main() function without parameters.
This function will be launched when the project is launched.
The main function can perform one of tree roles:
The main function directly performs operations with various protocols using a single virtual user without the use of agents:
Read more in the Operations
The main function, using controller object method calls, executes one or more scenarios using a specified number of virtual users on one or more agents:
Read more in the Test plan
A combination of the first two fields with any number of operation calls and launches of virtual user groups in any order.
To import additional script files, simply use the standard JavaScript syntax.
When using remote agents, all additional scripts will be automatically transferred to them along with the main one before the test is performed.
Optional global object for project configuration. It can contain any set of child objects described below.
The simplest example for configuring SLA:
Test configuration.
The SLA (Service Level Agreement) automatically checks that the test results match the specified metrics.
Metrics can be set for all operations in the Global section or for individual operations in the corresponding sections with the name of the operation:
Metrics for controlling the number of errors allow you to filter out the allowable number of random disturbances.
Duration metrics allow you to control the performance components of any operations.