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.
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.
