Browser Emulation
Emulating Different Browser Types
Software, such as browsers, that retrieve and process web content are known as user agents. User agents often send a User-Agent request header thus identifying themselves when requesting Web content. By default, the User-Agent request header set by your generated web script is that of the browser/software used during recording.
It is possible to set the User-Agent header to a custom value, thus making the server believe that its receiving requests from a particular browser type or other Web client. Your generated web script contains a call to setUserAgent. Edit this method within the script to set the User-Agent to a value other than that which was recorded. Alternatively, set up a Data Dictionary value with the name User-Agent (see the chapter on data parameterization).
Concurrent Connections
The original HTTP Protocol Specification states:
Clients that use persistent connections should limit the number of simultaneous connections that they maintain to a given server. A single-user client should not maintain more than 2 connections with any server or proxy.
By default, Eggplant Performance conforms to this specification. However, web pages contain many more references to stylesheets, images and external JavaScript files than ever before. With the advent of more powerful servers, browser developers have been steadily increasing this limit. Raising the number of concurrent connections allows sites to download more content in parallel, which should translate into faster page download times when bandwidth is available.
Changing the Web Virtual User Concurrent Connection Limit
If you want to emulate a browser (User-Agent) with a higher concurrent connection limit than 2 then you can use a function from the Eggplant Performance Web API. Placing a call to setPageResourceThreadCount() in your script will ensure that any Virtual Users running that script will use the new concurrent connection limit. If you want to apply the limit to a Virtual User type then place the call in a custom Virtual User. Any scripts based upon the custom Virtual User will inherit the new limit.
WinInet Concurrent Connection Limit
This WinInet discussion is only applicable to Windows-based Injectors.
When replaying Web Virtual Users using WinInet as the HTTP(S) handler you will need to ensure that WinInet allows the number of concurrent connections you require. To change WinInet's maximum connections per server, update the registry on every machine that is participating as an Injector in your test.
HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Internet
SettingsMaxConnectionsPerServer REG_DWORD (Default 2)
Sets the number of simultaneous requests to a single HTTP 1.1 Server
Update the registry carefully, as it can be dangerous if not done correctly. You should back up the registry before making any changes.
Eggplant Performance's Internal HTTP(S) handler and the WinHTTP HTTP(S) handler honor the page resource thread count limit set by the setPageResourceThreadCount() method.