Minimum OS Level Permissions Required to Install LoadRunner

Though it's recommended to be either a local admin or member of the power user group to carry out LR installation, however, there are few occasions where due to security reasons it's not possible for your organization to give you those rights, in that case, there is still a possibility for you to carry out installation with minimum possible rights which are mentioned below in detail:

a.Full access (read/write permissions) to registry keys under:

HKEY_CURRENT_USER\Software\Mercury Interactive 
HKEY_LOCAL_MACHINE\Software\Mercury Interactive

b.Full access (read/write permissions) to the file system to be able to copy files.

If there is any problem either with agent startup or connection from Controller to the agent on a Windows 2000 machine with a power user, try the following: 
1. Open the Local Security Settings window through Start -> Programs ->Administrative Tools -> Local Security Policy. 
2. Select Security Settings -> Local Policies -> User Rights Assignments. 
3. Add the user to the "Create global objects" policy

Advantages and Disadvantages of Using Loadrunner Vugen’s Run Time Viewer

By reading the title of this post, you might be wondering that I can only see advantages of using Run Time Viewer during script development and what could be its disadvantages?

Though, run time viewer provides visual verification checkpoint to determine weather your script is able to navigate through the recorded actions successfully or not. However, this should NOT be used as a final verification point due to below reason:

Run time viewer is not an Internet Explorer (IE). This is a utility embedded within HP LoadRunner which has very limited functionality compare to IE in displaying advanced technologies elements e.g. ajax, applets etc. So, in case if any of the pages will not be displayed by Run Time Viewer, this does not mean that your script has anything wrong or not working. To verify that, you should be replaying your script with full extended logs enabled and review replay logs to check for any error or warning messages.

Another issue I have seen by keeping the run time viewer enabled during replay in my past experience (especially with Oracle NCA protocol script ) is that, the  vugen crashes during script replay. To get rid of this issue, HP recommended to turn it off during replay.

Important point to be considered:

It's good to use Run Time Viewer during script replay, however, do not use it as final verification to determine the script successful replay. Do check replay logs and application under test logs (if accessible) to decide that. Also, in case vugen crashes during script replay with run time viewer enabled, try to disable it to get rid of this issue.

LoadRunner Vugen's Run-time Settings > Preferences > Advanced option WinInet replay instead of Sockets (Windows only)

LoadRunner's (LR) default engine is Socket based, which is of course more lighter and scalable than the WinInet engine. However, based on my experience, I have seen few situations where script replay fine only with WinInet engine. This may solve the problem in shorter term, however, may introduce scalability issues in case huge number of virtual users needs to be executed on the involved injectors. Socket mode replay uses an HP proprietary interface to the network card providing a lighter engine that is  scalable for load testing and compatible with both Windows and non-Windows Load Generator machines.


WinInet replay uses the Microsoft WinInet DLL to talk to the network card. The limitations of the WinInet replay engine is 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 interface is used by Internet Explorer and is optimized to work with this browser. It supports all of the features incorporated into the Internet Explorer, and thus, WinInet replay can resolve some replay errors and may produce faster replay transaction times than using the Sockets mode replay.


Important point to be considered:
Only use the WinInet replay if the load test will run in a completely Windows environment with a relatively low number of Vusers are required to run on each Load Generator.

LoadRunner’s Vugen Run Time Setting Miscellaneous->Multithreading-> Run Vusers as Thread or Process

Though by default Vugen Run Time setting (RTS) is set to run vuser as thread, however, I have seen sometimes testers are struggling to understand why they should use the default setting and why not go for run vuser as process? To sort this confusion out, I thought of writing this article with detailed reasoning behind it.

It’s strongly recommended to set this RTS as 'run vuser as thread'. Reason behind this is explained below in the table which demonstrate the difference between these two settings:

RUN VUSER AS THREAD	RUN VUSER AS PROCESS
When you run Vuser as a thread, LoadRunner (LR) will launch 1 thread per vuser.  e.g. if you will run 50 vusers, LR will launch only 1 process (mdrv.exe) with 50 threads running within that single process (if the limits is set to 50, it can be less or more based on what you customize it from the default value which is 50).	When you run Vuser as process, LR will launch 1 process (mdrv.exe) per vuser. e.g. if you will run 50 vusers, LR will launch 50 mdrv.exe processes.
Running vuser as thread will be more effective on keeping the OS resources consumption on the injector’s boxes to considerably low as this setting does not have very heavy footprints.	Running vuser as process will be very heavy on OS resources consumption on the injector boxes
As multiple threads running within a single process share the available resources among themselves , it’s recommended to use this setting when huge number of vusers are required to run on the injector boxes	As each vuser has its own process and privately allocated resources, it’s not recommended to use this setting when huge number of vusers are required to run on the injector boxes

 

Important points to be considered:

• You will need to check with your development team if application is thread safe or not. If it’s not thread safe, then you may have to choose run vuser as process because running vuser as thread will not work with your application.
• By default, LoadRunner configurations have 50 as the max limit on the number of threads which can run within single process. Though you can increase this number, however, it’s good to keep in mind that by increasing this limit to some unreasonable number will make system/injectors unstable. So, it’s strongly recommended to keep it as default unless HP recommends you to do so.

How to add Windows Resource Monitor in LoadRunner Controller to monitor OS metrics?

In order to monitor OS resources of the machines under test (in case you have admin rights) and the LoadRunner boxes during test execution, we can use Windows resource monitor available in LR controller. Windows resource monitor uses “PERFMON” OS level utility at the background to fetch OS metrics, so you would either need to have admin rights or power user rights on the box against which you would like to carry out OS monitoring using this monitor. In case there is any firewall between LR Controller and the box to which you would like to monitor, 139 port needs to be opened as well.

 

Below are the step by step instructions on how to add Windows Resource monitor in LR Controller and select required OS counters for monitoring: 

• In LR controller, Go to RUN tab. Under System Resource Monitor-> Select “Windows Resource Monitor” and drag to the area where we have graphs available.

 

 

• Right click on Windows Resource Monitor graph -> Select Add Measurements option.

 

• Click on Add under “Monitored Server Machines” section. Add machine name and OS whose resources you would like to monitor during test execution.

 

• Enter Machine Name and select the appropriate platform/OS, Click OK. While trying to add a remote machine for monitoring, sometimes you do get pop up box to enter credentials which LoadRunner will use to login to that box and fetch these details. Once the machine is added successfully, all the counters will be populated in the bottom half of the screen as shown below:

 

• Select the specific counters which you would like to monitor during test execution, and click on Add button to add them in controller. In case you will not select any counter and will click on OK, all the counters will by default get added in the controller for monitoring purpose.
   

 

It’s a very good practice to use this monitor during test execution, so I encourage all of you to use it going forward and do let me know in case any further information required.

 

P.S: For Windows OS, windows resource monitor can be used. Similarly, for Unix/Linux based OS, UNIX Resource monitor can be used. Please do note that HP encourages to use SiteScope to monitor Unix/Linux type of OS instead of LoadRunner monitor due to various known issues.