Showing posts with label Vugen. Show all posts
Showing posts with label Vugen. Show all posts

Tuesday, 11 November 2014

Process Explorer - Powerful tool to assist in identifying LoadRunner Vugen recording Issues

Microsoft Process Explorer is a very powerful tool to help you to identify certain types of recording issues e.g vugen is unable to record script as few of the application running on your machines are interfering in LoadRunner mechanism to place a hook on the communication flows between client and server or antivirus is causing issues etc.
Process explorer displays processes running on your machine, and associated dlls/exe invoked.The unique capabilities of Process Explorer make it useful for tracking down DLL-version problems or handle leaks, and provide insight into the way Windows and applications work.


Below steps explains how to use while trying to identify/troubleshoot recording related issues:
a. Having installed this program, run 'procexp.exe'. This launches the application.
b. The top half of the screen list all the processes running on the machine. Click on menu 'View | LowerPane View -> Dlls' and then the second half of the screen displays the list of DLLs used by the process which is highlighted in the top half of the screen.
c. Click on menu 'View | Select Columns' and under the Process Image tab check 'Image path'. Now under the DLL tab, make sure you have Path selected as well.
d. Now bring up VuGen and start your recording. After you have done so, come back to process explorer and select 'Vugen.exe' as the process and then have a look at the Dlls listed below. Now click on File | Save in a notepad file.

You can get detailed information and download it from below link:
http://technet.microsoft.com/en-gb/sysinternals/bb896653

Thursday, 6 November 2014

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.