By default, LoadRunner uses its own sockets implementation, which is very robust and allows use of hundreds of virtual users per load generator during a test. However, under certain conditions the sockets implementation does not seem to work. Or so it seems.
During one of our client engagements, recording of a script using Web (HTTP/HTML) protocol proceeded smoothly. However, its replay failed. The target URL failing was using https protocol. The error recorded in Vugen was step-download timeout exceeded which was set to the default of 120 secs. This is a common error that typically means something went wrong and the server did not return a response to the client’s request within the timeout value. The URL in question simply fetched a WSDL. All major browsers (IE, Firefox and Chrome) on that machine were able to successfully retrieve the WSDL without any issues. Turning on Advanced trace and Print SSL options in VuGen did not provide any clues. It seemed like LR was making the request but nothing much was being returned from the server.
Turning on the WinInet option in run-time settings of VuGen immediately made the output window of VuGen a beehive of activity. The server responded immediately. This option essentially allows LoadRunner to use Internet Explorer’s HTTP implementation under the covers. Using this option, everything that IE can do is made available to LoadRunner. Unfortunately, the use of WinInet option comes with a penalty. According to LoadRunner documentation (v.11.51), this option is not as scalable as the default sockets implementation. HP product support indicated that if using WinInet option allows script replay then that is our only option. Luckily, we found a workaround by staying patient and using Wireshark to look under the covers. Incidentally, Wireshark is a fantastic tool to add to your performance testing arsenal if you haven’t already.
Making a recording of the traffic in Wireshark while the URL was accessed in Internet Explorer and comparing it to a recording made while the LoadRunner script was replayed in VuGen showed a problem during SSL handshake. The difference was immediately apparent just watching the traffic in Wireshark (best to use a display filter if your network is as chatty as our customer’s). IE was using TLSv1 protocol in order to make the request to the server while LoadRunner was trying SSLv1 and SSLv2 protocols, which although dated are still popular. It is not clear if the server itself was configured to respond only to TLSv1. But LoadRunner NEVER tried to use TLSv1 during handshake with the server. A quick read of VuGen’s documentation clarified that LoadRunner uses only SSLv1 and SSLv2 by default. By using web_set_sockets_option(“SSL_VERSION”,”TLS”) function and AND turning off the WinInet option allowed replay to work without a hitch. As a result we now have a scalable scenario to test our web application.
- Navigate to the folder containing openssl.exe (typically <LoadRunner installation folder>/bin on Windows).
- Enter openssl s_client -connect google.com:443