Tag Archive: loadrunner



Issue: “communication between vugen and the truclient browser could not be established”. This error occurs when we click the ‘Develop Script’ button.

Solution: Simple step, Run the Vugen.exe as ‘Administrator’.

Advertisements

Inorder to start scripting the SAP applications using the Loadrunner tool, we have to enable the scripting mode available in the SAP application apart from the normal script enabling setting.

Please use the TCode – RZ11

Navigate to the page it allows and change the settings to ‘FALSE’ for the below mentioned parameters.

a. sapgui/user_scripting_set_readonly and set the value as “FALSE”
b. sapgui/user_scripting_force_notification and set the value as “FALSE”

TY


In Loadrunner script, we use block size per vuser for using the huge range of unique values in a parameter. But during the test, if the execution failes inbetween its very hard to re-allocate the block size again by checking the unused values. In-order to solve this issue, we can use the LR_ADVANCE_PARAM function in loadrunner. Please find below the usage format to implement this.

 
Action()
{
int x,y,v,i;  // declare these variables as integer
v=atoi(lr_eval_string(“{VuserID}”));  // get the VuserID and store it in v
i=atoi(lr_eval_string(“{ItNum}”));  // get the Iteration number and store it in i
if(i==1)
 x=v;  // For the first iteration, x = VuserID
else
 x=6;  // For the second iterations onward, x = No of Vusers  + 1 (assuming Vusers = 5)
for(y=1;y<x;y++)
lr_advance_param(“CreatedCustID”);  // parameter file name (keep settings as Sequential Once)

————-

———-

———
return 0;
}


Note: checkboxvalueRaw is the list of correlated values which is being listed in the check boxes. It has to be checked in random numberr and submitted.

int i, j;

char checkboxvalue_param[100],temp_param[60], temp1_param[60];

web_reg_save_param(“checkboxvalueRaw”,”LB=XXXXX”,”RB=YYYYY”,”ORD=ALL”,”Notfound=warning”,LAST);

          i=1;

          j=(rand()%(atoi(lr_eval_string(“{checkboxvalueRaw_count}”)))+1);

          lr_output_message (“i is %d, j is %d”, i,j);

          do     

                   {        sprintf (checkboxvalueRaw_param, “{checkboxvalueRaw_%d}”, i);

                             lr_save_string(lr_eval_string(checkboxvalueRaw_param), “checkboxvalue_sel”);

                             strcpy(temp_param, temp1_param);

                             strcat(temp_param, lr_eval_string(“{checkboxvalue_sel}”));

                             if (i<j)

                             {

                                      strcat(temp_param, “,”);

                             }

                             strcpy(temp1_param, temp_param);

                             i=i+1;

                   }

                   while (i==j);

lr_save_string(lr_eval_string(temp_param), “checkboxvalue_sel”);


char newvalue[15]=”I Love India”;

long pfile;

char *filename = “C:\\Sample.txt”;

pfile = fopen( filename,”a+” );

if(pfile == NULL)

{

printf( “Error in opening the filename – %s “,filename );

}

fputs(newvalue,pfile );

fputs( “\n”,pfile );

fclose( pfile );


Hp-Sitescope

(1) Agentless monitoring tool

(2) No memory consuming tool.

Hp-Diagnostics

(1) Agent required tool

(2) Memory will be consuming in the monitoing servers. Even this may tend to affect the performance of the web application.


Issue: After the scenario has been set up with certain load generators, while starting the scenario we face some errors due to Load generators.

Solution: Note the scripts for which the particular load generator has been used. Open the .prm file for the particular scripts. We can see the mismatch of parameterization name from the script to the prm file of the corresponding script. Now modify the parameter name which is correctly given during parameterization in the script.

Once it is changed and restart the scenario, it will run successfully.


LoadRunner:   Anatomy of a Script

When you record and save a LoadRunner script in Vugen, there are a number of files that are created. Here’s what they are, and what they do and identification of the files you can safely delete..

Files Required for Playback
During the course of recording and playback of scripts, the Vugen application will create many files, but only some of them are necessary for playback (either in Vugen or the Controller).

For example, say you have script named PerformancEngineer, with two Actions, Home and Forums, then the required files you would need in the PerformanceEngineer script directory would be:

* PerformanceEngineer.usr
* default.usp
* default.cfg
* globals.h
* Home.c
* Forums.c
* vuser_init.c
* vuser_end.c
* PerformanceEngineer.prm

Here’s what is in each file:

PerformanceEngineer.usr: Primarily, the .usr file defines which actions are used by the script. There are other properties which define which protocols are used and other settings, but most of the info

default.usp: Contains the run logic for the script

default.cfg: Contains the run-time settings (except for run-logic)

globals.h: The global headers file- visible and editable in Vugen

*.c (Action files): These are the action files containing your script code. You can edit these files in any text editor, if you want. Sometimes it is easier than starting up Vugen

PerformanceEngineer.prm: Containes the parameter definitions

*.dat: Your data files, you can save these in the script directory or somewhere else, even a mapped network drive on a different server
Files Created During Vugen Playback

All of the files listed below can safely be deleted and not affect your ability to use the script.

result1: One or more result directories are created which contain script playback results

*.idx: The .idx files are binary “index” files created by Vugen for holding parameter values

PerformanceEngineer.ci:

combined_PerformanceEngineer.c: A list of #includes for all of your Actions

logfile.log, mdrv.log: random log files which you will probably never need to look at

mdrv_cmd.txt, options.txt: These text files contain commands and arguments for the script compiler and driver (mdrv) and are created dynamically, so you can safely delete them.

output.txt: This one is important. This file contains all of the log messages generated during script playback. The contents of this file appear in the “Output Window” section of Vugen

output.bak: A backup of the above file

pre_cci.c: Output from the C pre-processor, which contains all of the functions used in your scrip, from all of the Acitons and header files.

In summary, you can delete: *.txt, *.log, *.idx, *.bak, result*, pre_cci.c, combined_*, *.ci
Files Created During Recording

The ‘data’ directory in your script directory contains the script recording data. I usually delete this so it doesn’t get checked into my version control system, but you may want to keep it around if you use the graphical scripting mode and/or you want to compare playback vs. recording. The auto-correlation feature makes use of this data, too, but I haven’t had much sucess using that feature.

(This has been referred from the site performanceengineer.com)


Working with a firewall means that you can prevent unauthorized access to or from a private network, on specific port numbers.

In a regular LoadRunner load test scenario (not over a firewall), the Controller has direct access to the LoadRunner agents running on remote machines. This enables the Controller to connect directly to those machines. When running Vusers or monitoring applications over a firewall, this direct connection is blocked by the firewall. The connection cannot be established by the Controller, because it does not have permissions to open the firewall.

LoadRunner solves this problem by using a communication configuration based on HTTPS or secured TCP/IP. This configuration uses the standard SSL port on the firewall (port 443).

A LoadRunner agent is installed on load generators running Vusers over a firewall, and on Monitor Over Firewall machines that monitor the servers that are located over a firewall. The agent communicates with the MI Listener machine through port 443 in the firewall. The MI Listener is a component that serves as router between the Controller and the LoadRunner agent.

When the LoadRunner agent connects to the MI Listener, the MI Listener keeps a listing of the connection to the agent using a symbolic name that the agent passed to it. When the Controller connects to the MI Listener, it communicates to the MI Listener through port 50500.

Setting Up your System to Use Firewalls:

Basic Steps Setting up your system to use firewalls involves the following stages of configuration: Installation and initial configuration Running Vusers over a firewall Installation and initial configuration

To enable over-firewall communication, ensure that you have installed the following LoadRunner components:

MI Listener Monitor Over Firewall component To perform initial configuration of your over-firewall system:

1 Configure your system according to TCP or HTTPS.

2 Modify your firewall settings to enable communication between the machines on either side of the firewall.

3 Configure the MI Listener.

Configuring the MI Listener To configure the MI Listener:

1 Open incoming HTTPS service for port 443. The port settings are set by your system administrator.

2 Stop the LoadRunner agent on the MI Listener machine by right-clicking its icon in the system tray and selecting Close from the popup menu.

3 Run MI Listener Configuration from Start > Programs > LoadRunner > Advanced Settings, or run \launch_service\bin\MILsnConfig.exe.

4 Set each option as described in the following table:

5 Click OK to save your changes, Cancel to cancel them, or Use Defaults.

6 Restart the LoadRunner agent by double-clicking the shortcut on the desktop, or choosing Start > Programs > LoadRunner.

7 Make sure that port 443 is free on the MI Listener machine.

Running Vusers over a firewall

To set up your system to run Vusers over a firewall:

1 On each load generator machine that will be running over a firewall, configure the LoadRunner agent to communicate with the MI Listener.

2 Configure the Controller machine to recognize the load generator and MI Listener machines.

Configuring LoadRunner Agents Over the Firewall

1 Stop the LoadRunner agent by right-clicking its icon in the system tray and selecting Close.

2 Run Agent Configuration from Start > Programs > LoadRunner > Advanced Settings, or run \launch_service\bin\AgentConfig.exe.

3 Select the Enable Firewall Agent check box, and then click Settings. The Agent Configuration dialog box opens.

4 Set each option as described in “Agent Configuration Settings”

5 Click OK to save your changes, or Cancel to cancel them.

6 Restart the LoadRunner agent by double-clicking the shortcut on the desktop, or select Start > Programs > LoadRunner > LoadRunner Agent Service/Process.

7 Check the connection status between the LoadRunner agent and the MI Listener.

Configuring the Controller for Running over a Firewall

1 Run the Controller from Start > Programs > LoadRunner > Applications > Controller and create a new scenario, or load an existing one.

2 Click Generators to display the Load Generators window. In the Name field, enter the symbolic name of the server. This is the same name that you entered in the Local Machine Key setting in the Agent Configuration.

3 Select the Load Generator, and click Details to display the Load Generator Information.

4 In the Security tab, enter the MI Listener machine’s name in the MI Listener field. This is the same name that you entered in the MI Listener Name setting of the Agent Configuration dialog box. In this example, the MI Listener is bunji.

5 In the Firewall Settings section, select one of the following options: ➤ Enable running Vusers over Firewall. To run Vusers over the firewall. ➤ Enable Monitoring over Firewall. To monitor Vusers over the firewall.

6 Click OK to return to the Load Generators dialog box.

7 Select the load generator and click Connect. This will do all the setup required to run your test over the firewall…


All files located in %temp% and %tmp% folders of the Controller, VuGen, and LoadGenerator machines can be safely removed after a script has been saved, the scenario run, and the results collated, analyzed, and saved.

 

The following are temporary files created by LoadRunner:

 

The Brr_xxxx folder contains raw data collected by the Controller during runtime. These data will be collated and copied to the result folder after the scenario completes and are safe to delete if collation completes.

 

The lr5tmpdirLNL.xxx folder contains runtime information of the load test and is safe to delete.

 

The unq1Ln.xxx folder is another runtime information folder; it contains information about monitors and is safe to delete.

 

Res is the default result folder, you should move it to a different location for safe keeping. You can also specify the result folder by selecting Result -> Result Settings in the Controller.

 

Aes_log.txt, drv_log.txt, ResmonLog.txt, ResmonLogBrief.txt, and LoadRunner_agent_startupYAR.xxx.log are all log files and are needed only for debugging purposes in case of a problem.

 

Noname*, vuac*, vxml*, and unq* are all script-related files and can be removed once the script has been saved.

 

JET1858.tmp is an MS Jet temp file used during the collation process. It is safe to delete once collation finishes.