Skip to end of metadata
Go to start of metadata

Modern browsers issue requests in parallel to download webpages faster. StresStimulus simulates concurrent requests by mimicking the browser’s behavior based on the following test factors:

  • Page breakdown information.
  • Types of simulated browsers in the mix.
  • Types of simulated network bandwidth in the mix.
  • Server responses.

It does not use the information about parallel connections collected during the recording because this information is not fully relevant to the emulated test conditions. Emulated browser types can be different from the browser type used for recording. Also, the server load during test run is typically higher than the one during the recording.

The following behavior is emulated for every page and for every VU independently:

1. Issue primary request and wait for the response. During this time all dependent requests are blocked.
2. Receive the primary response and handle dependent requests, which can be issued in parallel or sequentially.

    1. Parallel dependent requests. Dependent requests, representing webpage resources, such as images or style sheets, are typically sent in parallel, using multiple connections. The number of connections depends on the maximum number of available concurrent connections supported by the emulated browser. Each browser type has two limits: Max connections per hosts and Max connections per proxy. Both limits are enforced, so the number of connections per any single hosts and the number of total connections are independently limited. All other dependent requests, if any, are blocked (queued). As responses are being received, some of the queued dependent requests are being issued without violating the browser's connection limit constrain. Additional blocking rules are imposed to prevent issuing subsequent dependent requests until certain critical responses are received. These rules follow standard browsers specifications.
    1. Sequential  dependent requests. Some dependent requests on a page must be issued sequentially, according to the page logic.  For example, a video player on the page request subsequent  video fragment after receiving and processing previous fragments. Some MIME types (e.g. Text/HTML) are always requested sequentially. Depending on the tested application, you can add additional MIME types whose requests must be issued only after receiving all previous responses. This will prevent dependent requests of these types from being requested in parallel with other dependent requests on a page. To do so, in Configure Test -->  Other Options, in the property MIME Types requested sequentially, click the drop-down and enter additional MIME types. Separate multiple entries by ",". For example, enter "image,video", as shown below, to request all images and videos sequentially; or enter "video/mp4" to Request MP4 video sequentially. After modifying this property, launch test wizard and rerun autocorellation.


Info: Sent and received traffic cannot exceed emulated network type bandwidth limits. To achieve this the traffic can be appropriately slowed down.


3. After the last dependent response was received, the current page is finished processing.

4. Optional think time delay is injected.

5. The VU is ready for processing the next page.

You can change the default request concurrency by changing the page breakdown, as described in the next section.


  • No labels