Disabling and Enabling Rendezvous Points in Load runner

Rendezvous Points:
During a scenario run, you can instruct multiple Vusers to perform tasks
simultaneously by using rendezvous points. A rendezvous point creates intense user
load on the server and enables LoadRunner to measure server performance under
load. arrives at the rendezvous point, it is held there by the Controller. You then set a
rendezvous policy according to which the Controller releases the Vusers from the
rendezvous point either when the required number of Vusers arrives, or when a
specified amount of time has passed. You define rendezvous points in the Vuser
script.

B. Using the Controller, you can influence the level of server load by selecting:

1. Which of the rendezvous points will be active during the scenario?
2. How many Vusers will take part in each rendezvous?

C. Include lr_rendezvous(“rendezvous_name”); on the top of the start transaction
where the rendezvous of all the Vusers must occur in the VuGen script.

D. Howto Set Up a Rendezvous in a Scenario?

Prerequisites:

To set up a rendezvous in the scenario, your scenario must include Vuser scripts that
have rendezvous points inserted in them. When you add a Vuser group or script to
the scenario, LoadRunner scans the included scripts for the names of the rendezvous
points and adds them to the list of rendezvous points. You can see the list of all the
rendezvous points in your scenario by selecting Scenario > Rendezvous.

Note: In goal-oriented scenarios, a script’s rendezvous points are disabled.

Set the level of emulated user load

Select the rendezvous points to take part in the scenario, and the number of Vusers
to participate in each rendezvous. You can temporarily disable a rendezvous and
exclude it from the scenario. You can disable a rendezvous point for all Vusers in a
scenario, or you can temporarily disable specific Vusers from participating in the
rendezvous. By disabling and enabling a rendezvous, you influence the level of server
load.

 Set the attributes for the rendezvous policy – Optional

In the Rendezvous Information dialog box, for each rendezvous:
a. Select the rendezvous, and click the Policy button.
b. In the Policy dialog box, set the policy attributes as follows:
I. Release. How many Vusers will be released from a rendezvous at a time.
II. Timeout. How long the Controller waits before releasing Vusers from a rendezvous

By disabling and enabling rendezvous points, you can influence the level of server load

Disabling a rendezvous temporarily removes it from the rendezvous list and excludes it from the scenario.

Enabling a rendezvous returns it to the Rendezvous list and includes it in the scenario.

You use the Disable and Enable commands to change the status of rendezvous points during a scenario.

To disable a rendezvous: 

1 Open the Rendezvous window. The Rendezvous menu appears in the LoadRunner menu bar.

2 Click a rendezvous. The selected rendezvous is highlighted.

3 Choose Rendezvous > Disable, or click the Disable button. The rendezvous name changes from black to gray and the rendezvous is disabled.

To enable a rendezvous: 

1 Open the Rendezvous window. The Rendezvous menu appears in the LoadRunner menu bar.

2 Click a disabled rendezvous. The selected rendezvous is highlighted.

3 Choose Rendezvous > Enable, or click the Enable button. The rendezvous name changes from gray to black and the rendezvous is enabled.

Difference between HTML, URL Mode Recording in Load runner

HTML Mode:

• Default and recommended recording mode.
• Records HTML action in the context of the current Web page so that all we see on a web page will be recorded in a single function which makes it easier to read.
• Advantage of this mode is that it generates a script that is intuitive to the reader in terms of what is the form requesting (in a form of entire web page).
• Best for browser applications.

URL Mode:

• Instructs VuGen to record all requests and resources from the server. It automatically records every HTTP resource as URL steps.
• Generates a script that has all known resources downloaded for your viewing which works good with non-HTML applications such as applets and non-browser applications (e.g. Win32 executables).
• Having everything together creates another problem of overwhelming low-level information and making the script unintuitive. Difficult to read.
• When there are unrecognizable requests made to the server in Web (HTTP/HTML) protocol, they are recorded as web_custom_request. However, in URL-mode, this can be selected to allow recording to default to web_custom_request.

GUI Mode:

• Introduced with Web (Click & Script) protocol.
• GUI-mode option instructs VuGen to record all editable fields in an object or non-browser applications. What it does is to detect the fields that have been edited and generate the scripts accordingly.
• Concept similar to functional testing when objects are detected at theGUI-level. When reading the script, it allows easier reading as the script is based on the GUI presented to the real user. Easier to read in context of the object.
• Best for applets and non-browser applications.

Creating dll files and using it in LoadRunner scripts

Creating DLLs have tons of advantage, especially when you want to take your scripts away from the beaten path. I won’t blabber much in this post and would like to take you people right into the topic I want to cover.

In the previous post I mentioned about Search And Replace function. To serve the purpose of an example, I have recreated the same Search And Replace function in VC++(2010) expresss edition and built a DLL file.

Below is the code that created in VC++:

#include "stdafx.h"
#include "C:\Program Files\HP\LoadRunner\include\lrun.h"

extern "C" __declspec( dllexport ) int lr_searchReplace(char* inputStr, char* outputStr, char lookupChar, char repChar);

int lr_searchReplace(char* inputStr, char* outputStr, char lookupChar, char repChar)
{

char *ptr =inputStr;
char xchar;
int len=0;
int i=0;

lr_output_message("%s",inputStr);
xchar = *ptr;//Copy initial
len=strlen(inputStr);
while (len>0)
{

len--;
xchar = *ptr;
if(xchar==' ')
{
inputStr[i]= repChar;

}

ptr++;
i++;

}

lr_save_string(inputStr,outputStr);
lr_output_message("%s",inputStr);

return 0;
}


Before attempting to build this dll project in VC++, ensure that you have included lrun50.lib in the aditional linker file settings which is in Project Options, else the project won't successfully build/compile. lrun.lib should be present inside \lib folder. Also make sure you include the lrun.h header file as shown in the above code snippet.

After the project is built, dig into the debug folder to find the dll file and then copy it inside the LoadRunner script folder and use it as shown below:

Action()
{
lr_load_dll("SearchNReplace.dll");
lr_save_string("this is a dummy text", "cProjectName");
r_searchReplace(lr_eval_string("{cProjectName}"), "convProjName", ' ', '+');
lr_output_message("%s",lr_eval_string("{convProjName}"));
return 0;
}

Creating a custom .DLL file in LoadRunner

Sometimes LoadRunner does not provide all the needed features that one needs when doing performance testing. One option is to write DLL’s to handle the needed stuff and writing your own custom DLL’s is really easy once you get the hang of it!

I needed to do a few HTTP calls “under the radar” from a script so using Delphi 2009 I wrote my own HTTPClient DLL that allows me to do a HTTP GET to a specific URL without adding to the statistics (Pages and Hits/Sec stats).

Creating DLL’s in Delphi is really simple. One of the things I had to keep in mind was that D2009 uses unicode internally so I had to take care to convert any internal strings to non-unicode before returning them to LR. I opted for using the Indy 10 component TIdHTTP as the base HTTP client, adding some Cookie handling and Compression support (gzip,deflate) and making sure the DLL was thread safe (as many client threads/process would be using it). I also soon realized I needed HTTP Proxy Support so in the end I added that too.

Finally had a DLL that exported the following methods:
http_Initialize( VUserID: Integer )
http_WebProxy( VUser: Integer; Host:PAnsiChar; Port: Integer )
http_WebGet( VUserID: Integer; URL: PAnsiChar; DestBuf: PAnsiChar; BufSize: Integer )
http_Finalize( VUserID: Integer )

The VUserID is the identifier for the connection since the DLL supports keep-alive. Calling Finalize() will destroy all cookies and disconnect the client from the server.

 Sample script:

vuser_init()
{
int ret, VUserID;
char buf[10240];

// Get VUserID
VUserID = atoi(lr_eval_string("{VUserID"));

// Load the DLL
lr_load_dll("HTTPClient.dll");

// Initialize the VUser object inside the DLL
http_Initialize( VUserID );

// Set the HTTP Proxy
http_WebProxy( VUserID, "127.0.0.1", 8080);

// Clear buffer, and get the URL's response
memset(buf,0,sizeof(buf));
ret = http_WebGet( VUserID, "http://www.google.com", buf, sizeof(buf) );

// Check for error
// Returns
// 0 != Insufficient Buffer (Returned value is needed size)
if (ret != 0) lr_error_message("Error: RetCode=%d", ret)
else lr_output_message("%s", buf);

// Finalize the VUser (free the VUser object inside the DLL)
http_Finalize( VUserID );

return 0;
}


An additional good thing with this is that the DLL can be loaded under ANY protocol, so now HTTP calls can be made in any script type!