Different browsers can have a dramatic effect on a web application’s performance. In order to accurately test an application’s performance, it is important to emulate different browsers to understand how the application’s behavior and network utilization are affected. Here are some helpful tips to maximize your efforts.
When using a UI level script, such as TruClient, the browser is fully emulated. This can affect the performance test as follows:
- Real page rendering is performed, and uses the exact same method as the emulated browser. This may include HTML, CSS, images and more. It takes time that is not spent in a network-level script.
- The actual cache logic for the selected browser is used.
- The actual proxy logic for the selected browser is used.
- The actual User-Agent for the selected browser is used.
- Connection behavior, such as connection limit and keep-alive timing, is determined by the actual browser.
When using a network-level script, such as Web (HTTP/HTML), no actual browser is used. However, different browsers can and should be emulated to correctly simulate the load on the application under test (AUT).
The most common (and simplest) way of emulating different browsers in network-level scripts is by sending different User-Agent headers. The User-Agent header is sent to let the AUT know what browser, version and locale sent the request. Different User-Agent headers can affect the AUT’s behavior as follows:
- The AUT may use different server logic for different browsers, which can cause different response times.
- The AUT may send different responses to different agents. For example, modern applications often try to send a mobile-compatible version of the pages to mobile agents.
- The mobile-compatible version might use lower-resolution media to save bandwidth.
- The mobile-compatible version might return only a subset of the content, in order to reduce the download size.
- The AUT may have different connection limits, keep-alive limits, etc. for different agents.
The result, from a performance engineer perspective, is that the AUT experiences a different load when accessed by different User-Agents.
You can determine the User-Agent header used by the script during replay from the Run-time Settings dialog, in the Browser -> Browser Emulation -> User Agent option.
Another way to emulate different browsers in network-level scripts is to limit the number of concurrent connections used by the Virtual User for connecting to each host.
For example, IE6 uses two connections per host, while IE9 and Chrome both use six connections per host by default.
In LoadRunner, this can be emulated in the following ways:
- By default, a new Virtual User script will send the User-Agent header compatible with IE6.
- The first time a script is recorded, the User-Agent header sent by the recorded application will be added to the script runtime settings, to be used during replay.
- In the Run-Time Settings configuration, you may change the selected User-Agent string to emulate specific browsers, as described in the Run-Time Settings section of the LoadRunner User Guide.
- While the script is replayed, the maximum number of connections per host is determined by the emulated browser. For example, the virtual user will use two connections when emulating IE6, and six connections when emulating IE9.
- In the script itself, you can call the web_set_sockets_option function to set a different connection limit. This will override the Run-time Setting for the browser.
You can emulate other aspects of browser behavior using the following advanced options and configurations:
- Configure a browser-specific cache behavior using the relevant options in the Run-time Settings dialog’s Browser -> Browser emulation -> Simulate browser cache option.
- Configure browser-specific proxy behavior using the relevant options in the Run-time Settings dialog’s Internet Protocol -> Proxy node.
- Turn DNS caching on or off, determine locale behavior, SSL behavior and more, in the Run-time Settings dialog’s Internet Protocol -> Preferences -> Set advanced options section.
- Use the many options available from the web_set_sockets_option function.
Many thanks to Oded Keret from LoadRunner R&D for providing the information for this post.
Let us know which browsers you emulate in your performance tests by leaving a comment below.