Syntax example:
clients=5
Sets the amount of virtual clients.
Syntax example:
requests=10
Sets the number of runs of the main cycle [TestSeq] for each virtual client. E.g. if the settings are Clients=10, Requests=20 and there is a single HTTP request declared in [TestSeq], the overall number of [TestSeq] cycle runs performed by all virtual clients will make 10x20=200, thus 200 HTTP requests will be sent to the server. If there are 5 HTTP requests declared in [TestSeq], then the overall number of [TestSeq] runs in this test will remain the same - 10x20=200, but the amount of HTTP requests sent to the server will make 10x20x5=1000.
Limits the maximum overall amount of requests made by all virtual clients. When this number is reached, all virtual clients will be stopped - disregarding the amount of requests made by each particular client.
This setting can be useful when measuring the precise value of Requests per second. Usually the chart of server load chart with multiple virtual clients looks as follows:
The reason of the stepwise character of the load rise at the initial stage was described earlier (see Delaystart). The reason of the stepwise character of the final stage is similar: it is both the fact that not all virtual clients start at the same time, and the various work times of particular clients (which can differ significantly).
Web Roller calculates the Requests per second value in the following manner:
Requests per second = Total requests made / Working period
where:
Working period - the overall time spent for processing all requests - from the time of sending the very first request till the end of processing the last one;
Total requests made – the overall number of requests made. Calculated as:Clients x Requests x (Total number of requests in [TestSeq] section)
Thus the Requests per second value is measured incorrectly, since constant load is not provided during the Working period. You cannot provide accurate conclusions about application performance tested under a specific load (200 virtual clients in our case).
The method of avoiding the starting "steps" is described in Delaystart. The MaxRequests setting allows in turn to avoid the final "steps". The required actions are:
- Set an excessive value of Requests (e.g. 1 000 000);
- Set the MaxRequests value so that the amount is sufficient for correct calculation of Requests per second (i.e. if we set MaxRequests=10, then the value of Requests per second calculated using only 10 requests can be claimed to have a great calculation error and thus cannot be used as a realistic estimate; if we set MaxRequests=10000, then you can consider the calculation error to be acceptable).
It also a good idea to consider also the running time of the script when setting the MaxRequests value - e.g. if the script successfully performs 10000 requests in 5 seconds, than the Requests per second will be calculated with a noticeable error).
Attention!
You need to remember that Requests sets the amount of runs for the [TestSeq] sequence which can include multiple HTTP requests, while MaxRequests sets the maximum amount of processed HTTP requests for ALL clients. The MaxRequests value should be significantly less than the value of Total requests made (see above for the calculation of this value), calculated for the case when MaxRequests equals to 0 (i.e. not used).
The maximum time for running the test (seconds). The test will run until all requests will be processed, or until the run time exceeds Maxtime.
Caution!!!
For this setting to be active, the amount of requests should be big enough so that all requests are not processed before Maxtime elapses.
Determines whether to abort the current sequence [TestSeq] for all virtual clients if Maxtime is reached, or to wait for normal sequence termination.