How to ensure LoadRunner script replay sucessfully when BASIC type of authentication used by an application under test?

When your application under test (AUT) uses BASIC authentication, and you have replayed the default recorded and enhanced script ( e.g. parameterization, correlation etc. ), it may fail as the authentication process sends the first 401 handshake and fails on the second with an error such as 501.


To check if your application uses BASIC authentication or not, you can of course check with your development team or check in the response header in the vugen replay logs. To resolve this issue and achieve successful replay, you can actually add below function at the very beginning of the action section and then replay your script:
   web_set_sockets_option ("INITIAL_BASIC_AUTH", "1");

 

Upper limit on the timeout placed in LoadRunner function web_set_timeout()?

Yes, there is an upper limit to the time which you can define in this timeout function. The limit is set to 1000 seconds. I certainly don't think there is any need to define timeout beyond this limit, as if your application is taking this long already to respond, which means this is something wrong with the application response itself and increasing the timeout further will not help.

And if you will try to place the timeout beyond 1000 seconds in web_set_timeout() function, you will see below error message in the replay logs:

"Error - 27285: setting the timeout value failed"

Difference between LoadRunner HTML or URL/HTTP recording mode

It is always recommended to use HTML mode unless problems arise where URL mode is necessary. There are a few cases in whihc URL mode is necessary. For example, if your application employs certain types of refresh directives (eg. meta refresh tags) to redisplay a correct page, URL mode would be necessary.

HTML mode differs from URL mode in that HTML mode script actively parse through the returned information to obtain resources to download. URL mode does not parse, thus; resources (eg. gif, jpg, etc...) will be directly scripted into the Vuser. This will also means that script length will be increased compare to the script generated in HTML mode. Which in terns increase the memory footprints of the URL script , and may cause issues if its required to run URL mode generated script for more number of vusers on limited number of available injector boxes.

When you set the HTML mode to record resources as separate steps, it may seem identical to the URL mode, but in fact isn't. HTML mode still employs the parsing engine to detect resources. Only resources that LoadRunner can not detect will be scripted in HTML mode, whereas; 'all' resources are scripted in URL mode.

This automatic parsing mechanism will help take care of many correlation issues related to the downloading of resources, thus; I strongly recommend HTML over URL.

What is "wasted time" and does it get included in the response time metrics calcualted by LoadRunner Controller\Analysis?

The concept of "wasted time" was introduced to distinguish between actual time spent on processing and displaying information, from Human/idle-waiting overhead. Wasted time is calculated as a factor of unnecessary waiting. In Vugen, the transaction time includes the "wasted time" but it is subtracted from transaction time when displayed in Controller and Analysis.

Below types of activities are considered as wasted time by LoadRunner:
1. Rendezvous is considered as wasted time, since the client Vuser could theoretically continue executing, but has opted to wait for other Vusers to meet at certain points of execution.
2. Any silent waits (i.e., via TE_wait_silent), where the context or text has already been displayed, but the Vuser still waits to ascertain that it is stable. (Functions such as TE_wait_text() have lr_wait_silent embedded in it.) This is to ensure that the text is actually stable before continuing. It is considered wasted time, since the Vuser really did not have to wait, but did just to make sure the text appeared and stabilized.
3. Any User Input time (think time) is considered wasted time, since the application is not engaged in processing or displaying information. Even if the typing style is modified (i.e., via TE_typing_style), the total duration of the typing is considered "wasted time."
4. Explicit sleep statements are not considered "wasted time" since it may be argued either way. If you want idle waits to be included in "wasted time," use TE_wait_silent().
5. For Winsock script, time to compare the difference between the receiving buffer and data in the data.ws is counted as wasted time.
6. For Web script, the time taken for web_reg_find or web_reg_save_param functions to look for a particular string in the response buffers, is counted as wasted time.

Though wasted time does not impact the response time metrics calculated by Controller and Analysis, however, it does impact the OS resources on the load generator box as it makes the session for a particular vusers to be held active for longer time than usual.

Number of vusers that can be run on a typical Load Generator

There are several factors that can affect the scalability of a script, and so the number of Vusers that can be run, it is not always possible to determine the hardware requirements to run a given number of vusers. The best approach is to run some tests to verify empirically the resource requirements of the specific scripts being used during a test.
Factors that can impact the number of vusers which can run on a load generator are:

1. Length of the business process or in other words script length
2. Complexity of the script e.g. custom code, correlation etc
3. Number of scripts needs to be executed in the test scenario
4. Protocol used to script the business flow in Vugen
5. Run time setting used “Run vuser as process” or “Run vusers as thread”. It’s recommended to use Run vuser as a thread option (default one) unless your application under test (AUT) is not thread safe
6. Level of the logs selected under Run time settings during test execution
7. Load generator machine is physical or virtual
8. Hardware configurations of the load generator machine. The primary factors affecting the script execution are Memory and CPU Utilization. Other factors such as Network Bandwidth and Hard Disk speed can become factors but in virtually all cases the core issue will be Memory and CPU related.

In order to determine the number of users that will run on a given Load Generator machine it is best to run some tests from the LoadRunner Controller. Create a scenario using the scripts in question where they are run on a remote Load Generator using a slow ramp up of vusers. During this process monitor that Load Generator to see what Memory and CPU resources are used as the load is increased. Note that in this case the "load" that we are talking about is the client side processing load on the Load Generator machine itself and not the load on the Server (which is what is normally measured during an actual load test.)

Using this method an accurate estimation may be made about how many vusers can be run on that machine. Also some extrapolation may be done to determine additional hardware requirements for additional vusers. It is also wise to monitor the Load Generator machines during the actual test to ensure they are not a bottleneck in the test (as that would invalidate the test results anyway.)

Some rules of thumb for monitoring load would be:
- CPU usage should stay below ~80-90% continuous usage.

- Memory usage should stay within the physical limits of the machines memory. This means that the "Commit Charge Total" should be less than the "Physical Memory Total" which will ensures that minimal paging is done to simulate physical memory.

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

Co-existence of LoadRunner and Quick Test Professional\Unified Functional Testing on same Machine

As LR and QTP\UFT binaries/installer has some of the files in common, this can cause issues for both the product to co-exist on the same machine, and eventually may cause crash any of these products while carrying out various testing activities.


Though I would strongly recommend not to install LR and QTP/UFT products on the same machine, however, if this has to done, you must ensure below sequence of installation is followed:


> LoadRunner should be installed first.
> Upon successful installation of LR, only then QTP/UFT should be installed