Appendix A: HTTP Test Executer Initialization File

The TestExecuter_web.ini Initialization file is copied to the AgileLoad bin directory when AgileLoad is installed. This file contains parameters that can be modified to customize the operation of the HTTP Test Executer.

If the TestExecuter_web.ini file is not found, the HTTP Test Executer uses the default parameter values.

This file has four sections: FILES, SOCKET, TEST and THREAD POOL. The parameters that may appear in each section are listed below.


This section contains parameters related to the HTTP Test Executer Trace file, Trace.txt. This file is located in the AgileLoad Engines directory.


Filters what information is output to the trace file. Range: 0-1000.
If this parameter is set to zero, or is not specified, the trace level is set to the value specified in the Trace Settings dialog within AgileLoad Center. However, if the trace level specified here is higher than that specified in AgileLoad Center, the higher trace level is used.
This allows the trace level for the HTTP Task Group Executer on each Host to be set independently.

Current supported values:

0 = Errors only (Default value)
10 = Low level tracing
20 = Medium level tracing
50 = Detailed tracing
1000= Full trace (this value can produce a large Trace file)


This section contains parameters related to socket I/O.


The number of memory buffers reserved to store received data. Each buffer is the size of the operating system's memory page (4Kb on x86). An exceedingly high value for this parameter will cause an unnecessarily large amount of memory to be reserved. This is not really a problem since the memory is not committed until it is actually required. A value that is too low will cause the test to fail because there is an insufficient number of buffers.
Default: 64000.


The number of buffers allocated to store received data when more buffers are required. Each buffer is the size of the operating system's memory page (4Kb on x86). The buffers are allocated from the reserved pool, whose size is specified by the MaxSocketDataBuffersCount parameter.
Default: 2000.


The maximum number of SSL buffers that it is estimated will be used at the same time.
This should be set to: No. of Virtual Users * No. of sockets (1 to 4) per Virtual User
Default: 8000.


The number of SSL buffers that will be allocated when more buffers are required.
Default: 1000.


Enable or disable TCP Keepalives. If this parameter is set to a value of 1, TCP Keepalives are enabled for all TCP connections established by the HTTP Task Group Executer. This causes the Executer to emit a TCP Keepalive, every second, after a TCP connection has been inactive for a period of time. On Windows 2000, this period is specified by the KeepAliveInterval parameter. On Windows NT, it is fixed at 2 hours. If an error is detected by a TCP Keepalive, an error message is logged to the Audit Log and Error Log and the associated virtual user is aborted.
TCP Keepalives can be used to prevent virtual users 'hanging' when no response is received for TCP requests issued on their behalf, i.e. due to the failure of a TCP connection. There is a slight performance hit in using this feature, so for greatest efficiency, it should be disabled if not required.
If this parameter is not specified, or is set to a value of 0, TCP Keepalives are disabled and virtual users will wait indefinitely for TCP requests to complete.
Default: 0


When TCP_KeepAlives is set to a value of 1 and the Executer Host is running Windows 2000, this parameter specifies the time period in milliseconds after which the HTTP Task Group Executer will emit TCP Keepalives for an inactive TCP connection.
Default: 300000


If set to 0, it avoids the presence of too many sockets on the injector machine with a TIME_WAIT status.
Default: 1


If 1, informs the Windows Sockets provider that a bind on a socket should not be disallowed because the desired address is already in use by another socket.
Default: 1


Specifies the socket timeout (in milliseconds). A connected socket that is not used during a period greater or equal to the timeout value is closed. When a timeout occurs, an error 258 is generated in the Audit log for the specified connection.
Default: 60000


An HTTP request that fails due to network error is automatically retried "Retry_Count" times.
Default: 4


If more than "ErrorPerSecond" network errors occur during 1 second, the corresponding Task group is stopped.
Default: 50


This section contains Test related parameters.


The number of Virtual User Control Blocks pre-allocated at the start of a Test. Pre-allocating Control Blocks avoids the overhead of allocating them during the Test. The optimum value for this parameter is the total number of Virtual Users that are to run during a Test. In this manner, no Control Blocks will need to be allocated during the Test-run, and, if at some time during the Test, all Virtual Users are executing simultaneously, all the Control Blocks will be in use.
Default: 1000.


The number of Virtual User Control Blocks allocated when more Virtual Users are required during a Test-run.
Default: 20.


This section contains parameters controlling the behavior of the thread pool.


The number of concurrent threads. A value of zero indicates one thread per CPU.
Recommended range: 0 - (4 * number of CPUs).
Default: 0 (1 thread per CPU).


The number of threads available in the thread pool. A value of zero creates a thread pool size of 25 * ThreadPoolConcurrentThreads.
Recommended range: 0 - 100.
Default: 0 (25 * ThreadPoolConcurrentThreads).

Setting the MaxSocketDataBuffersCount Parameter

This parameter will be ideally set to the maximum number of buffers that are required at any one time. This means that no superfluous space is reserved and all reserved space is used.

One way of calculating this value is to estimate the maximum number of buffers required for a socket on a thread and then to perform the following calculation:

No. of Sockets per VU * No. of VUs * Max. no. of buffers required per socket.

This allocates enough buffers for each Virtual User to process the largest item concurrently. This may not be realistic, for example, if the largest item is very large compared to others and is not processed very often.

Another way of calculating the value, is to determine a more realistic value for the number of buffers required by an individual user across all sockets and then to perform the following calculation:

No. of VUs * No. of buffers required per VU (across all sockets).

The received data buffer size is equal to the size of the system's memory page (4Kb on x86).

How the above may be used in practice is probably best illustrated by an example. Consider a very simple HTTP test specifying 10 virtual users, each issuing no more than 2 requests in parallel: a 2Kb HTML page, containing a 23Kb GIF image.

The first formula above would result in a value of 120 for MaxSocketDataBuffersCount, i.e.:

2 * 10 * 6 (No. of Sockets per VU * No. of VUs * Max. no. of buffers required per socket).

Why 6? Because 6 buffers (4Kb each) are required to receive 23Kb (the size of the largest item). However, in this example there are only two items to be processed, so if one socket is processing the GIF image (23Kb) then the other socket must be processing the HTML page (2Kb). Therefore, the second formula above would be more appropriate and would result in a value of 70 for MaxSocketDataBuffersCount, i.e.:

10 * 7 (No. of VUs * No. of buffers required per VU (across all sockets)).

Why 7? Because 7 buffers (of 4Kb each) are required to receive 25Kb (23Kb + 2Kb the maximum size of the items to be processed concurrently by a thread).

Although the example is quite simple, it does illustrate how the two formulae can be applied in practice.

Below is a sample INI file:















Go back to the Learning center:

Copyright © AgileLoad. All rights reserved.
Agile Load testing tool| Contact AgileLoad | Terms of Use | Sitemap