How to capture the URL that is formed because of redirection?

Example:
When visiting http://www.mercury.com, user will be redirected to a different location. How to capture the redirected URL.


Solution:
Use web_reg_save_param()

When that the server redirects a HTTP request to another URL, it normally does that by sending a HTTP 302 Moved header. To verify
1. Run the script in extended log with "data retuned by server' turned on
2. Check the execution log for "302 moved'

You can also see that along with this header, the server also sends the following header information:
   "Location: ."

The URL specified in the "Location' header will be the URL that the original HTTP request be redirected to. To capture this URL, you have to capture the string between "Location:" and "\r\n" (end of line).

Example:

    Action()
    {

       //use the correlation statement to capture the redirection
       web_reg_save_param ("Redirection", "LB=Location: ","RB=\r\n" ,LAST );

       //Visit Mercury homepage
       web_url("Mercury","URL=http://www.mercury.com/", LAST);

       //Print the redirected URL
       lr_message("redirected address = %s", lr_eval_string("{Redirection}"));

       return 0;
    }

Difference between socketlevel and WinInet modes in load runner

WinINet uses the Microsoft interface to the internet.
Starting with version 7, Load Runner uses Sockets mode replay by default.This was also known as Turbo replay. Socket/Turbo replay utilizes its own interface to the network card. This proprietary replay engine is a lighter engine that is scalable for load testing.

The older WinInet replay, which can be enabled in Load Runner by selecting "WinInet replay instead of Sockets (Windows only)", uses the Microsoft WinInet DLL to talk to the network card. The limitations of the WinInet replay engine are that it is not scalable, nor does it support UNIX. In
addition, when working with threads, the WinInet engine does not accurately emulate the modem speed and number of connections. However, The WinInet is the engine used by Internet Explorer. It supports all of the features incorporated into the Internet Explorer, and thus, WinInet replay can
resolve some replay errors.

 attribute :
1) Additional attribute will be read from the run time settings of controller or VuGen.
2) We can pass the values to VuGen test script from the run time settings.
3) When you you change the value of the additional attribute, you do not have recompile or restore the test script in controller.

variable :
1) Variable will be defined in VuGen, based on the C data type.
2) Variable will be used for capturing any run time values or function return values.
3) When you change the value of the variable in the script, you have to recompile or restore the test script in controller.

parameter :
1) Parameter will be defined in VuGen to store parsed response results for server dynamic values like user session id, item id which are automatically generated by the server .
2) Parameter will be used in the subsequent requests to successfully play back the script with captured dynamic server values .
3) When you change the parameter settings, you have to recompile or restore the test script in controller

WinInet “weighs” more in terms of over all system resources as it is integrated with the Microsoft security APIs. The sockets option, what used to be known as Turbo load  was developed to allow for lighter weight virtual users to exist in larger quantities on a given reference hardware definition (Load Generator). The core change is on playback, if you need integration with the Microsoft security infrastructure, i.e. using web_set_user() you will need to use WinInet and you will need to use Windows Load Generators. And yes, these users will use more system resources.

The default is sockets. Unless you need to integrate directly with a security infrastructure for user authentication you will likely not need WinInet. You use this mostly when you have recording issues related to security, consider the use wininet as a workaround since the sockets mode with the required port mappings is the correct solution.

Note:When an application fail in recording, you can try by switching between the two modes. Whereas when the application fails in replay, try switching the modes also.