A number of web-specific Runtime Settings are accessible from two additional tabs made available to a web virtual user (VU) group.
These settings are accessed by editing a VU Group and selecting the tab Runtime Settings > Web: Logging.
Web Page Logs
VU Selection Range: The Web logging feature enables the viewing of the resources returned to web VUs during replay. For localhost injectors the Web resources can be viewed in real-time whilst remote injector web logs can only be viewed at the end of a test run once all logs have been retrieved by the Controller. The web log is accessible from Test Controller. The web VUs to monitor are entered here.
Examples: 1,3,5 i.e. VU indices 1, 3, and 5 or 10-12 i.e. VU indices 10 to 12 inclusive)
Maximum logfile size: The Web log is a circular buffer of fixed size. Once full the beginning of the log is overwritten. A circular buffer is used to ensure that disk space is not filled to capacity during soak or very long test runs. It is advisable to ensure that the size is large enough to contain at least one iteration's worth of data.
Log Contents Detail: Moving this slider changes the level of detail recorded in the log for HTTP requests. At its minimum setting it will contain only resources with content type text/*. Increasing the detail level will include non text resources such as images. Normally, you will be interested in text only.
Time every HTTP request: If checked, timings will be recorded for every HTTP request and made available for results analysis. These timings are in addition to transaction and timings created as a result of startTransaction() and startTiming() method calls within the script. See Large Test Runs for information.
Include query data in request label: Each HTTP request that is timed has to be identified by a label. If checked, the label identifying the timing is the full URL including query data. If unchecked, the label excludes the query data within the URL; this will result in less timing labels as many requests share a common URL excluding query data. The query data is the part of a URL following the '?' symbol.
These settings are accessed by editing a Virtual User Group and selecting the tab Runtime Settings > Web: Options.
Sub-request thread count: Modern browsers use multiple threads to send and receive requests to and from the web server in parallel. The number of threads to use can be set here. Generally, the more threads used, the faster the pages will load (especially for complex dynamic websites), up to a point at which the overhead of multithreading exceeds the benefit.
Most modern browsers use at least 6 threads.
Maximum connect retries: Connections can sometimes be refused because the web server is overloaded, the server being unreachable, etc. Connections to the web server will be retried this number of times before the web VU declares an error and increments the network disconnection count. Once an error has been raised the web VU script abandons the current request and executes the next line of script code.
The following message in the web VU's event log is an indicator of a connection failure:
"Disconnect received retrying..."
Maximum network disconnections: Once the maximum number of network errors has been breached a web VU will abandon execution and generate a message in the web VU's event log. This message is of the form:
The network disconnection count is incremented by failures associated with the other setting detailed in this section.
Connect timeout (secs): A web VU will wait this amount of time on a connect request and if no response whether negative or positive is received it will declare an error and increment the network disconnect count. Once an error has been raised the web VU script abandons the current request and executes the next line of script code.
Receive timeout (secs): If a web VU receives no data within this time period it will raise an error and increment the network disconnect count. Once an error has been raised the web VU script abandons the current request and executes the next line of script code.
HTTP and HTTPS connection handlers
The Web runtime has the option of using a variety HTTP/S connection handlers. A connection handler manages the HTTP/S connections between a Web virtual user and the server. There are three types of connection handler available.
Microsoft's HTTP Services (WinHTTP) is a high-level interface to the HTTP/1.1 Internet protocol. It is compatible with Windows and NTLM authentication but is only suitable for use on Windows-based injectors. WinHTTP is preferable to WinInet in most circumstances.
WinInet is older Microsoft technology designed as an HTTP client platform and has been superseded in Eggplant Performance by the WinHTTP connection handler. It is compatible with NTLM authentication but is only suitable for use on Windows-based injectors.
Common SSL and non-SSL HTTP connection handlers. Select this option to ensure that both HTTP and HTTPS connections are handled by the same connection handler.
HTTP handler: Select from the list to determine the handler for HTTP connections.
HTTPS handler (SSL): Select from the list to determine the handler for HTTPS connections. This option is inactive if a common handler for both has been selected.
Cookie support: If checked, cookies are maintained on a VU by VU basis at runtime i.e. each VU maintains its own cookie cache. See Cookie handling.
Support gzip or deflate encoding: Check this option to support gzip or deflate encoding. This is used by servers to compress content in order to reduce network bandwidth. This option increases the processing load on both client and server. Only select this option if replicating clients that support gzip or deflate encoding.