The SecApps toolkit is built upon a powerful, asynchronous, HTTP request scheduling engine. The following options will help you configure various aspects of the engine's behavior.
This option is used to configure the maximum allowed elapsed inactivity time before the connection is concluded. By default, the timeout is set to 30 seconds.
Reduce the timeout if you expect the majority of the requests to be unresponsive. This means that the engine will wait less time per-request and as a result will be able to emit more requests per second as defined by the "Max Connections" option.
Alternatively, you may want to increase the timeout if it is expected to see increased network latency. This will typically occur if the application is unresponsive or the network or intermediary nodes are slow at transferring data.
In some circumstances, the built-in HTTP client can automatically supply credentials such as cookies and basic, digest and NTLM authentication headers. If this option is disabled, the client will send the request as is without taking into consideration the current session and execution context.
This option is particularly useful when testing for the point of view of multiple authenticated users.
The "Max Connection" option defines the total number of requests that can run concurrently at any given point in time. If the value is set to 2 and there are currently two requests in the pipeline each taking 10 seconds to complete, this means that the scheduler will be able to execute about 12 requests per minute. Alternatively, a value of 60 will produce 360 requests per minute.
It is important to consider the impact of increased concurrent connections. For example, the application server or any other intermediate node, such as proxy servers, may drop or throttle requests based on the total number of currently active requests from the same client. If you are planning to send a lot of requests it is generally advisable to test first with a small sample to see how the application server will behave. If there is no change in application behavior during increased load time, it is safe to increase the number of concurrent connections.
Decreasing the maximum concurrent connections will increase the time required to complete the tasks. With relatively small tasks this is not an issue. If you are planning to send thousands of requests with very low concurrency value the task will take noticeably longer.