2.1 What is the Purpose of Load Runner?
LoadRunner is used to create a load or stress on a system, and can be used to measure the responsiveness of the system to that load. The key concept behind LoadRunner is the use of virtual users, or vusers. To perform a load test, a system needs many users to access the system concurrently, often one hundred or more. Performing such a test with people is a logistical nightmare. LoadRunner overcomes this problem through the use of vusers.LoadRunner is a Testing Tool used for Testing the Performance of an application by emulating an environment in which multiple users work concurrently. LoadRunner will apply load on the application and Test Maximum Load an application can support. While the application is under load, LoadRunner accurately measures, monitors and analyzes a system’s performance and functionality.
2.2 The components of the LoadRunner.
1. VirtualUserGenerator
The virtual user generator is used to generate scripts for all non-GUI vusers. The virtual user generator records the behavior of the client software, and automatically generates a script that can be used by the controller to run vusers.
2. Controller
Once vuser scripts have been created, they can be added into the controller in varying quantities to produce the demand on the system that is required.
3. Analyzer
The load analyzer utility presents the results of running a scenario in a variety of graphical and tabular forms. These graphs and tables can be used to determine the acceptability of a system, and to determine areas of concern.
2.3 What is the Sequence to use LoadRunner?
Creating Vusers Scripts.
Here, we create Vuser scripts that contain tasks performed by each Vuser, tasks performed by Vusers as a whole, and tasks measured as transactions by using VirtualUserGenerator.
Creating the scenario.
A scenario describes the events that occur during a testing session. It includes a list of machines, scripts, and Vusers that run during the scenario. We create scenarios using LoadRunner Controller. We can create manual scenarios as well as goal-oriented scenarios. In manual scenarios, we define the number of Vusers, the load generator machines, and percentage of Vusers to be assigned to each script. For web tests, we may create a goal-oriented scenario where we define the goal that our test has to achieve. LoadRunner automatically builds a scenario for us.
Running the scenario.
We emulate load on the server by instructing multiple Vusers to perform tasks simultaneously. Before the testing, we set the scenario configuration and scheduling. We can run the entire scenario, Vuser groups, or individual Vusers.
Monitoring the scenario.
We monitor scenario execution using the LoadRunner online runtime, transaction, system resource, Web resource, Web server resource, Web application server resource, database server resource, network delay, streaming media resource, firewall server resource, ERP server resource, and Java performance monitors.
Analyzing test results.
During scenario execution, LoadRunner records the performance of the application under different loads. We use LoadRunner’s graphs and reports to analyze the application’s performance.
3. CONTROLLER
3.1 About controller
More than one Vuser can be tested using the Load runner Controller. Controller will execute the scenarios .It will make hundred of vusers running in the single system.
3.2 Procedure for creation of scenario in controller.
LoadRunner Controller is used to manage and maintain scenarios (events that occur during each testing session).
To run a scenario
1. Start->Programs->Mercury LoadRunner->Applications-> Controller
By default the controller opens with the NewScenerio dialog box. If it does not open on startup you can open it by choosing File->New.
2. You can select one of two methods to create a scenario: Manual Scenario or Goal-Oriented Scenario. In a manual scenario, you create the scenario yourself by defining the number of Vuser groups you want to run, and building a schedule for LoadRunner to run these groups. You can also create a manual scenario by defining the total number of users to be used in the scenario, and assigning a percentage of the total number of Vusers to each script. If you want to create a scenario using the Percentage Mode, select Use the Percentage Mode to distribute the Vusers among the scripts.In a goal-oriented scenario, you define the goals you want your test to achieve, and LoadRunner automatically builds a scenario for you, based on these goals.
3. Select the script you want to run the scenario.
4. In Design view give the Quantity (No of vusers) and Click editschedule button and set the settings according to the requirements.
The Load Runner Controller enables the creation of scenario which are of two types:
Manual Scenario
You build a manual scenario by creating groups and specifying the script, the load generator, and the number of Vusers included in each group.
When the Load Runner is launched the above screen comes up. Scripts can be added to the scenario by clicking on the Add Button. The other buttons are self-explanatory and for their explanation please refer to the LoadRunner Controller Users Guide Chapter 5.
Manual Scenario Design Tab
The Scenario Schedule Pane describes the Schedule Name, Mode, Scenario Duration and Load Behaviour. These will be described in greater detail in the section on scheduling a scenario.
The Scenario Groups pane lists all enabled and disabled Vuser groups, their paths,the load generator machines, and the number of Vusers assigned to each group.
3.3 Configuring runtime settings
The configurations of settings that have been used for Maconomy Load Testing are:
Run Logic: the number of iterations decided on the scenario
Pacing: As soon as the previous iteration ends.
Log: The messages should generally be logged at the level of Standard Log. However Extended Logging can be enabled when doing some investigation into a problem especially for sending Result Files to mercury for their investigation. But for the purpose of performance testing Extended Logging should never be enabled as it will adversely affect the results.
Think Time: This should generally be as Replay Think Time, Use Random percentage of recorded think time(50%to 150% ) and Limit Think time to 5 seconds. These are no hard and fast values and can be changed if considered suitable.
Miscellaneous: Use default.
Speed Simulation: Use default
Browser Emulation: Use default
Proxy: No proxy (default condition)
Preferences: Use default except for Advanced Options. Click on options button. In the Advanced Options box select change the following:
HTTP-request connection timeout (sec) to 1000 seconds
HTTP-request receive timeout (sec) to 1000 seconds
Step download timeout (sec) to 1000 seconds
Content Check: Use default.
3.4 Configuration of Load Generator
Clicking on the Generator tab opens up a box as shown below:
The load generator, which actually generates the load, is installed on a machine which is separate from Controller. So the name or the IP address of the machine needs to be added against the script as shown in the Scenario Groups screen shot. The screenshot above gives a ready reference of all the load generators that have been configured and their status.
3.5 Scheduling a Scenario
An important factor in creating a scenario is developing a test that actually portrays user behaviour. The type of actions is captured is by the Vuser script. Scheduling the script captures the timing of actions.
It is essential that the scenario of a test is accurately estimated otherwise the usefulness of the results of Load Testing might be undermined. Load Runner provides various techniques for creating an acceptable simulation of Real life scenario.
Through the Scenario Start dialog box shown in the screen shot below:
You can instruct Load Runner to begin executing a scenario with a delay, or you can specify the number of minutes you want the Load Runner to wait after the Run command has been executed. You can even specify the specific time at which you want the scenario to begin executing.
Through the Scenario Builder as displayed below you can control the execution of your scenario by limiting the scenario duration, gradually running Vusers within a scenario, gradually stopping Vusers within a scenario. Please refer to appendix 1 on how to simulate work load models.
• Limiting the Scenario Duration: The scenario can be made to run until completion, can be made to run for a certain duration after rampup, or can be run indefinitely. If the scenario is made to run for a certain duration after ramp up then irrespective of the number of iterations the scenario will run for the defined time.
• RampUp: All the Vusers can be made to run simultaneously or a delay can be given between groups of Vusers before they start running. In Maconomy generally we need to give a ramp up time to reduce the levels of concurrency in Transactions and also to more accurately simulate the real life scenario as its highly unlikely that all the users would be performing the same transaction at the same time. The ramp up time, generally given for Maconomy is ‘10 users every 30 seconds’. But any suitable value can be given.
• RampDown: There are two options either all the Vusers can be stopped simultaneously or a certain number of users can be brought to a stop in a certain timeframe.
3.6 Scheduling a Vuser group
After creating a Vuser group, you can schedule the groups script execution by setting:
• The amount of time after the start of the scenario that the group must wait before it starts running
• The number of vusers that will run within a specified period of time
• The number of Vusers that will be stopped within a specified period of time
• The amount of time the group will run
To schedule a Vuser group select the ‘Schedule by Group’ option in the scenario builder to get the box as shown below
The Start Time Tab gives the time delay between the start of the Scenario and the start of the Group. The other three tabs have basically the same meaning as explained above for ‘Scheduling by Scenario’.
3.7 Rendezvous Point
Rendezvous points are used to cause multiple Vusers to perform tasks at exactly the same time, there by creating intense user load on the server.
The rendezvous point can be inserted at any point in the script before the transaction that you want to be performed under concurrent load.
From the Vugen menu go to Insert->Rendezvous in the box that comes up enter for the rendezvous point.
Setting the Rendezvous Policy
1. From the Controller menu choose Scenario->Rendezvous. The Rendezvous Information dialog box opens.
2. Select a rendezvous from the Rendezvous box, and click the Policy button.
3. In the Policy section, select one of the following three options;
• Release when X% of all Vusers arrive at the rendezvous
• Release when X% of all running Vusers arrive at the rendezvous
• Release when X Vusers arrive at rendezvous.
From the point of view of Maconomy we might need to measure some important transactions like Costing, Printing through rendezvous points.
The rendezvous points can be temporarily disabled/enabled from a scenario.
3.8 Starting the Scenario
Click on the start scenario button.
In the Run tab of Scenario you will be prompted to enter the path of the results directory as shown in the screen shot below
Enter any suitable path for the results directory. And click on OK. Once this is done the scenario will start executing.
The run tab of the scenario will look as below.
The vusers will move from Down->Pending->Init->Ready->Run state.
You can view information on Transaction Response Times, Number of Running vusers as the scenario runs. Any errors that come up during the run will be immediately highlighted as red against the errors field. (in the Scenario Status box). Trouble Shooting of commonly occurring errors will be explained later in the document. The errors that occurred during the execution of the scenario are stored in a mdb file in the results folder.
Clicking on the vusers button will give information on the status of each of the vusers whether they are initialising/running/passed/failed etc through the below window that comes up.
Clicking on the highlighted icon will give the execution log for the selected vuser as shown below.
Once the scenario has run fully all the vusers would have moved to the Passed/Failed/Error Status and there would be no vuser in running mode.
LOADRUNNER GENERAL PROBLEMS AND LIMITATION
Problem Description: The Controller uses up all the memory though no scenario is running.
Problem Description: The Controller stops responding if a load test scenario issues a high number of errors
Problem Description: How to send the Controller output information to a file instead of viewing it from Controller itself
Problem Description: Are past Execution logs from VuGen saved somewhere
Problem Description: How to enable logging in Controller and where are Vusers log files stored
Problem Description: How to change the Execution and Recording logs to collect different amounts of information
Problem Description: How to disable mdrv###.log files under Vuser hosts
Problem Description: How to enable logging in Controller and where are Vusers log files stored
Problem Description: Where are the results of the WinRunner scripts stored for the GUI Vusers
Problem Description: The output.mdb file is blank after executing a scenario
Problem Description: The Controller displays "Loading Data..." but the error text is not shown in the output window
Problem Description: Generator or Vuser or Show output or Error or Transaction window does not open in the Controller
Problem Description: How to stop Vusers so they exit directly rather than gradual exiting
Problem Description: How to renumber Vusers in LoadRunner 7.5 or above
Problem Description: How to refresh Vuser scripts in the Controller
Problem Description: How to remove the scripts that are listed in "Available Scripts"
Problem Description: How to initialize more than 50 Vusers at a time
Problem Description: Common connectivity problems between Controller and Generator
Problem Description: Error: "-29989: Process 'lr_bridge.exe' was not created..."
Problem Description: How to run a scenario from the command line (Controller's Command Line Arguments)
Problem Description: How to run a scenario at a specific (absolute) time
Problem Description: Setting scenario start time in LoadRunner does not work
Problem Description: Wlrun.exe does not close when executing a scenario via command line option
Problem Description: How to read in string/text content from the command line in the Controller
Problem Description: Running LR from the command line does not collate results from a remote machine
Problem Description: Running LR from the command line does not collate results from a remote machine
Problem Description: How to modify the heartbeat time-out
Problem Description: How to set the "Save as" directory opened by VuGen or Controller
Problem Description: Cannot connect to the host machine from the Controller
Problem Description: Can the user run multiple Controllers using a network installation
Problem Description: Can different versions of LoadRunner be used together in a scenario
Problem Description: How to enter a new license key for LoadRunner
Problem Description: Accessing the Output window in the Controller increases the size of output.mdb
Problem Description: Some Vusers do not wait for other Vusers at the rendezvous point
Problem Description: C++ run-time error when running a Scenario
Problem Description: Scenario scheduler does not ramp down at the specified time
Problem Description: How to show more than 20 measurements in the Controller online monitor
Problem ID: 26375
Problem Description: The Controller uses up all the memory though no scenario is running
The Controller seems to be utilizing all the memory resources. Without any scenario running, the user noticed that the memory utilization for wlrun.exe increase drastically.
Diagnosis:Some processes or services on the machine might be interfering with the normal Controller operation.
________________________________________
Solution: Identifying processes that might interfere with the Controller
To verify the processes or services that might interfere with the Controller, you can use the Process Viewer. This application helps to list all the DLLs that are loaded.
Apart from that, it has been observed that the following might interfere with wlrun.exe:
• VNC (Virtual Network Computing) client
• SPYWARE ( using software like Ad-Aware )
• ExeSpy2000
Problem ID: 21925
Problem Description: The Controller stops responding if a load test scenario issues a high number of errors
The LoadRunner Controller stops responding if a load test scenario issues a high number of errors during scenario execution.
________________________________________
Solution: Configure the Controller to write errors to a text file
By default, the Controller writes errors to an Access database (output.mdb, created in the scenario results).
Work-around:
Configure the Controller to write errors to a text file.
Problem ID: 15075
Problem Description: How to send the Controller output information to a file instead of viewing it from Controller itself
________________________________________
Solution: Set "ExportMessagesToFile" to 1 in wlrun7.ini
Starting with LoadRunner 7.5, the output window information is saved in output.mdb file under the resutls folder . To set LoadRunner to use a different database, you need to go to Analysis -> Tools -> Options -> Database and set the database default before running a scenario.
If you need to view the data using a text file, you will need to
1. Run the Controller once and shut it down to reset the configuration files
2. In order to set /unset the text file mode please open wlrun7.ini using a text editor. This file can be found in your systems WinNT folder, or in your accounts 'WINDOWS' directory. Simply do a quick search for this on your hard drive.
3. Go to the [output] section and set "ExportMessagesToFile" to 1. If you do not see this entry, add it as following
[output]
ExportMessagesToFile=1
Note:If these messages are not important and you cannot prevent them then you can block these messages by making the following change in the wlrun7.ini (Close the Controller before making these changes):
[output]
BlockOutputMessages=1
************************************************************************
Problem ID: 15827
Problem Description: Are past Execution logs from VuGen saved somewhere
The user executed several runs in VuGen, are all the Execution logs saved?
________________________________________
Solution: Only the most recent Execution log is saved as output.txt in the main script directory
Execution logs are saved in output.txt in the main script directory. However, it is always overwritten during each run in VuGen. You need to back up the output.txt file after each run in order to save each Execution log.
Problem ID: 17005
Problem Description: How to enable logging in Controller and where are Vusers log files stored
________________________________________
Solution: Set the Run-Time settings to 'Always send messages'
To turn on logging for the Vusers in the Controller
1. Go to the Run-Time settings
2. In the log tab, select "Always send messages"
3. You can set the log detail level as you wish
4. Run the script
To see the message on the log file:
1. The Controller if the scenario is still up.
a. Click on "Vusers" in the Controller.
b. Right-click on one of the Vusers.
c. Select "Show Vuser log."
2. The result folder.
a. Go to the result directory (the location is specified in the Controller's Result-> Result settings).
b. Go to the "log" folder.
c. All Vusers' log files are saved as GroupName_VuserID.log.
Problem ID: 11377
Problem Description: How to change the Execution and Recording logs to collect different amounts of information
________________________________________
Solution: Turn on "Full Trace Recording Log" from the Recording Option
For extended Recording log information, look at the Tools -> Recording Options -> Advanced tab, which will allow you to choose "Full Trace Recording Log" to enable additional data collection. This option is available with the 'Single Protocol' template only.
For the Execution log, you want to go to the Vuser -> Run-Time Settings Log tab, which has three options for the Execution Log:
• Parameter substition - Prints the values of the parameters in your script.
• Data returned by server - All the HTTP data returned by the server.
• Advanced Trace - Additional information about the requests being submitted by the client.
Generating all three debugging options when running the script is the preferred method for debugging script exection. The data returned by server is the largest amount of data, and as long as you generate that, you might as well get the other two for added information.
The Execution log records all the information that is passed from the client to the server. It is the definitive guide to the conversation between the two. When debugging replay, it is important to realize the limitations of the Run-Time Viewer and turn to the Execution log to debug replay. Two tricks to speed up execution when replaying with the Extended log enabled are
1. Turn of resource downloading in the Run-Time Settings.
This will prevent all the binary data from being printed into the exection log (it is usually pretty useless anyway).
2. Click on the Recording Log tab during replay so VuGen does not have to update the Execution log on screen.
If you turn on the Extended log, it will generate large log files. Ensure you have enough disk space on which to store these files. If running a scenario with the Extended log, remember there will be a log file for each Vuser. Not only will this be a lot of large log files, but the host machine will spend a lot of time writing log files and not running Vusers, so fewer can run with the given resources compaired to when logging is disabled. It is not recommended to run a scenario with Extended log turned on.
************************************************************************
Problem ID: 3962
Problem Description: How to disable mdrv###.log files under Vuser hosts
________________________________________
Solution: Use command line option
For Unix hosts:
1. Add the script as usual to the Controller
2. Click on 'details...'
3. Click on 'more'
4. On the 'Command line' option, add the following:
-drv_log_file /dev/null
For Windows hosts:
1. Add the script as usual to the Controller
2. Click on 'details...'
3. Click on 'more' 4. On the 'Command line' option, add the following:
-no_drv_log
************************************************************************
Problem ID: 17005
Problem Description: How to enable logging in Controller and where are Vusers log files stored
________________________________________
Solution: Set the Run-Time settings to 'Always send messages'
To turn on logging for the Vusers in the Controller
1. Go to the Run-Time settings
2. In the log tab, select "Always send messages"
3. You can set the log detail level as you wish
4. Run the script
To see the message on the log file:
1. The Controller if the scenario is still up.
a. Click on "Vusers" in the Controller.
b. Right-click on one of the Vusers.
c. Select "Show Vuser log."
2. The result folder.
a. Go to the result directory (the location is specified in the Controller's Result-> Result settings).
b. Go to the "log" folder.
c. All Vusers' log files are saved as GroupName_VuserID.log.
Problem ID: 14559
Problem Description: Where are the results of the WinRunner scripts stored for the GUI Vusers
Where are the test results of the WinRunner scripts stored for GUI Vusers and how are they archived?
________________________________________
Solution: The test results are in the Temp directory of the machine on which the script is to be run
When running a load test, LoadRunner FTPs the WinRunner script into the Temp directory of the machine on which the script is to be run. The WinRunner results will be on that machine in the Temp directory. You will need to look for the WinRunner test script folder, which should be the same as if you were running WinRunner by itself, and the test results will be in the script folder.
The hard part will be determining which folder in the Temp directory was created as LoadRunner creates the folder dynamically. Check the date stamps of the folders and choose the most recently created one.
The load test results are saved in the location specifed in the Controller.
Problem ID: 22040
Problem Description: The output.mdb file is blank after executing a scenario
After executing a scenario using LoadRunner 7.5, the user notices the output.mdb file is empty even though there were a lot of errors, warnings, or output messages while running the scenario.
Diagnosis: The size of the output.mdb file is limited to 400 KB. If there are a lot of messages in the scenario execution (i.e., exceeding 400 KB), it will set the file to 0 KB.
________________________________________
Solution: Apply Patch LR75P26 - LoadRunner 7.5 Controller Fixes an empty mdb after Scenario finished running
This is a know problem in LoadRunner 7.5 with output.mdb where file size limitation is 400 KB. You need to apply Patch LR75P26 (LoadRunner 7.5 Controller Fixes an empty mdb after Scenario finished running) from the Patches database (Downloads -> Patches -> LoadRunner -> 7.5 -> General -> LR75P26) on the Customer Support website
************************************************************************
Problem ID: 22334
Problem Description: The Controller displays "Loading Data..." but the error text is not shown in the output window
When trying to open the error window in the Controller, the window appears, but hangs with the message "Loading Data...."
________________________________________
Solution: Upgrade the MDAC version on the Controller machine
This problem has been reported for the following cases:
1. MDAC version
You can find the MDAC version on your machine from Microsoft Knowledge Base Article 301202 - HOW TO: Check for MDAC Version. Make sure that you have MDAC 2.6 or higher installed. You can get the latest MDAC version from Free Downloads.
2. "List separator" setting
If you have a non-English environment, the "list separator" option on the machine is most likely set to be a semicolon. Go to Start -> Settings -> Control Panel -> Regional options, and under the "Number" tab, change the "list separator" to be a comma.
************************************************************************
Problem ID: 15350
Problem Description: Generator or Vuser or Show output or Error or Transaction window does not open in the Controller
Clicking on the "Generator" or "Vuser" or "Show Output" or "Error" or "Passsed / Failed transaction" button in the Controller does not open the window.
Diagnosis:The initialization file for the Controller is corrupted.
________________________________________
Solution: Delete wlrun7.ini from the C:\winnt directory
1. Close the LoadRunner Controller.
2. Go to the C:\winnt (or C:\windows for windows XP )folder and delete the wlrun7.ini file.
3. Go to
4. Reopen the Controller. The problematic windows should now open when you click on it.
Alternatively, if you do not wish to lose other settings, open wlrun7.ini in a text editor. Look for a section similar to:
[DockablePlace]
OUTPUT_FRAME_PLACE=113,846,587,1186,
TRANS_FRAME_PLACE=110,200,450,345
Simply replace the numeric values there, with the X coordinate of the window, its Y coordinate, width and height. "300,300,600,500," are usually reasonable values to start with. Then you need to save your scenario if necessary, and restart the Controller.
************************************************************************
Problem ID: 15390
Problem Description: How to stop Vusers so they exit directly rather than gradual exiting
________________________________________
Solution: Set the exit mode to "Stop immediately"
Open the Controller, click on the Run tab, and go to Tools -> Options -> Run-Time Settings. In the "When stopping Vusers" category, select "Stop immediately."
Problem ID: 15338
Problem Description: How to renumber Vusers in LoadRunner 7.5 or above
________________________________________
Solution: Renumber the Vusers in the "Run" screen
1. Go to the the Run screen of the Controller
2. Locate the "Group Name" column.
3. Right-click on the desired group name and select "Renumber."
Note: When you renumber the groups, the Vusers will change their IDs.
************************************************************************
Problem ID: 13604
Problem Description: How to refresh Vuser scripts in the Controller
After scripts have been modified in the VuGen, scripts in the Controller are not affected. How can the user make sure that updated scripts are being run?
________________________________________
Solution: Click on the "Refresh" button in Details
Go to the Design tab in the Controller and select one group. Click on Details, then click on the Refresh button. By doing this, the Controller will use the latest script in scenario. Follow the same procedure for all the groups in a scenario.
************************************************************************
Problem ID: 11297
Problem Description: How to remove the scripts that are listed in "Available Scripts"
How can the user remove the scripts that are listed in "Available Scripts" when creating a new scenario?
________________________________________
Solution: Delete the unwanted script entries from the registry
All recently accessed URL information is stored in the registry under HKEY_CURRENT_USER\Software\Mercury Interactive\RecentScripts.
To remove unwanted URL:
1. Go to Start -> Run and type in regedit to open the Registry Editor.
2. Open the HKEY_CURRENT_USER -> Software -> Mercury -> Recent Scripts folder. This lists all the files listed in the "Available Scripts" section when the Controller is launched.
3. Delete those entries you no longer want to appear.
Problem ID: 13349
Problem Description: How to initialize more than 50 Vusers at a time
During a scenario, the Controller will not allow more than 50 users to initialize at one time. This is in spite of the fact that the Vuser Quota for Initializations is set to 999 in the Controller's Tools -> Options menu.
________________________________________
Solution: The number of users that may be initialized is governed by two settings
The number of users that may be initialized at one time is governed by two settings. There is one overall setting that you can access under Tools -> Options -> Runtime Settings.
In addition to this, the initialization limit is also governed for each host machine.
1. Go to the Design Tab of the Controller.
2. Click on the "Generators" button. A new window will come up.
3. Bring up the Details of a generator.
4. Go to the Runtime Quota tab. This is where you will find an Initialization Limit for the host machine itself.
5. Set both limits accordingly.
Problem ID: 25162
Problem Description: Common connectivity problems between Controller and Generator
User is facing connectivity problems between Controller and Generator machines. The connection drops in middle of a scneario or can not connect to the Generator machine at all. LoadRunner returns the following eror :
Error: Load Generator failed.
Failed to connect - reason timeout.
Error -10343: Communication error: Failed to connect to remote host [server name: ]. (sys error message - ) [MsgId: MERR-10343]
Error -29989: Process "lr_bridge.exe" was not created on remote host "" ,reason - communication error. [MsgId: MERR-29989]
________________________________________
Solution: Troubleshooting a connectivity problem
Different problems can cause the above error. Some of the things you can verify include:
1. Make sure that you apply the same LoadRunner version and Service Pack on the Controller and Load Generator machines.
2. Make sure that you can ping the Controller and host machine bidirectionally. You may need to add the IP address and machine name on the host file:
a. Go to the host machine.
b. Navigate to C:\WINNT\system32\drivers\etc\.
c. Open the hosts file in a word editor.
d. At the end of the file, add another line with the IP address and machine name of the Controller machine.
Example:
111.111.111.111 MI_Controller
e. Repeat steps a - d for all the host machines.
f. Repeat steps a - d for the Controller machine, but adding the IP and machine name of the hosts machines.
3. Make sure that the LoadRunner Agent is running either as a process or a service on the remote host machine. Refer to Problem ID 10464- How to set LoadRunner Agent as a service or process after installation to do this.
4. Make sure the Controller and host are connected to the network. In some networks, the Microsoft LOOP back IP address 10.10.10.10 is used when a computer is not connected to the network. As a result, the Controller will not be able to detect the host machine. You will need to stop the loop back service, connect to the network, and make sure that the machine has a valid IP address.
5. If there are multiple network cards in the machines, please refer to Problem ID 11685 - Using LoadRunner with machines that have multiple NICs.
6. It might as well be possible that some network environment issue might be the cause and the network monitor can be used to diagnose the problem. Make sure that you are using the latest driver and firmware for your network cards and routers. Also try to force the network card to use 100Mbs/Full Duplex instead of the 'Detect automatically the best speed settings'. In case of miscommunication with the router or other network device the automatic settings could be set in an inappropriate way and have huge consecuencies on the network performances.
Problem ID: 11569
Problem Description: Error: "-29989: Process 'lr_bridge.exe' was not created..."
When trying to connect to a remote host using the hostname, the LoadRunner Controller gives the following error:
"- 29989: Process 'lr_bridge.exe' was not created on the remote host 'host_name', reason - communication error [msgId: MERR-29989]"
However, it is able to connect using the IP address.
________________________________________
Solution: Troubleshooting a connectivity problem
Different problems can cause the above error. Some of the things you can verify include:
1. Make sure that you apply the same LoadRunner version and Service Pack on the Controller and Load Generator machines.
2. Make sure that you can ping the Controller and host machine bidirectionally. You may need to add the IP address and machine name on the host file:
a. Go to the host machine.
b. Navigate to C:\WINNT\system32\drivers\etc\.
c. Open the hosts file in a word editor.
d. At the end of the file, add another line with the IP address and machine name of the Controller machine.
Example:
111.111.111.111 MI_Controller
e. Repeat steps a - d for all the host machines.
f. Repeat steps a - d for the Controller machine, but adding the IP and machine name of the hosts machines.
3. Make sure that the LoadRunner Agent is running either as a process or a service on the remote host machine. Refer to Problem ID 10464- How to set LoadRunner Agent as a service or process after installation to do this.
4. Make sure the Controller and host are connected to the network. In some networks, the Microsoft LOOP back IP address 10.10.10.10 is used when a computer is not connected to the network. As a result, the Controller will not be able to detect the host machine. You will need to stop the loop back service, connect to the network, and make sure that the machine has a valid IP address.
Problem ID: 13352
Problem Description: How to run a scenario from the command line (Controller's Command Line Arguments)
Is there a way to start the Controller via a Command Prompt?
Specifically, what arguments can be used to start the Controller, run an existing Scenario, shut down the Controller, and bring up the Analysis?
________________________________________
Solution: Command line arguments for the LoadRunner Controller
Note:
1. Make sure that the Controller is shut down before starting the scheduled task.
2. When running the Controller via the Command Line, Controller will be shut down automatically after the scenario ends.
Command line parameters are parameters that the Controller receives when it is invoked. They are used to instruct the Controller on how to behave. When invoked, the Controller checks all the received parameters and sets its startup environment accordingly. If no parameters are passed, the Controller uses its default settings.
By passing parameters in the command line, you may set the Controller and the scenario’s settings without the need to manually define them in the Controller UI. For example, you can instruct the Controller whether to connect to TestDirector on startup by using the ConnectToTD parameter, save the results to a directory other than that defined in the scenario by using the ResultName parameter, or invoke Analysis upon scenario termination with the InvokeAnalysis parameter.
The most common use of the Command Line is done by TestDirector. TestDirector includes a special program called "Test Run Scheduler," which was designed for scheduling the Controller to run scenarios at a specific date and time. It automatically invokes the Controller and runs scenarios. Results are saved in the TestDirector database. To do that, TestDirector must set the scenario’s environment by supplying the Controller with specific parameters.
Predefined rules:
• When one or more parameters are not passed, the Controller uses its default settings.
• Results will always be overwritten.
• The Controller will automatically terminate upon scenario termination and the results will be then collated.
• The Controller’s settings are loaded from wlrun5.ini located in the Windows directory.
• The following parameters are supported on all Windows 9x and Windows NT platforms.
Switches for LoadRunner/TestDirector integration:
• ConnectToTD - Should the Controller connect to TestDirector on startup (0/1 or ON/OFF).
• TDServer - TestDirector server name. Must be a computer name with TestDirector installed.
• TDDB - Database name. For example, "lrun."
• UserName - User name.
• Password - Password for the user name.
• TestPath - Path to scenario in the TestDirector database. For example, "[TD]\Subject\LoadRunner\Scenario1." If the path includes white spaces, use quotation marks.
• TestId – Test ID (for TestDirector only).
• ResultCleanName - For use with ResultCycle only, for example, "Res1."
• ResultCycle - TestDirector cycle, for example, "LR_60_SP1_247." To define the results path in TestDirector, the Controller must be provided with two parameters: ResultCycle and ResultCleanName.
Run-Time Switches:
• Run – Runs scenario, dumps all output messages into res_dir\output.txt and closes the Controller.
• InvokeAnalysis - InvokeAnalysis will set a flag in the Controller, which will invoke Analysis upon scenario termination (If not used, the scenario value will be taken).
Results Switches (for File System):
• ResultName - Full results path, for example, "C:\Temp\Res_01."
• ResultCleanName - Results name, for example, "Res_01."
• ResultLocation - Results directory. For example, "C:\Temp".
• Note:
o If the scenario does not specify a results directory and one of the above parameters was not passed, the scenario will not run!
o The results will always be automatically collated upon scenario termination.
o The results will always be automatically overwritten.
Command Line Syntax examples:
• Wlrun.exe –TestPath C:\Temp\Scenario1.lrs -ResultName C:\Temp\Res1 –Run –InvokeAnalysis
• Wlrun.exe –TestPath C:\Temp\Scenario1.lrs –ResultLocation C:\Temp –ResultCleanName Res1 –Run
• Wlrun.exe –ConnectToTD on –TDServer localhost –TDDB lrun –UserName yaniv18 –Passwordb#12GcSA –TestPath "[TD]\Subject\Trash for LR/TD Integration\Scenario1" –Run
• Wlrun.exe –ConnectToTD 1 –TestPath "[TD]\Subject\Trash for LR/TD Integration\Scenario1"
5. If there are multiple network cards in the machines, please refer to Problem ID 11685 - Using LoadRunner with machines that have multiple NICs.
6. It might as well be possible that some network environment issue might be the cause and the network monitor can be used to diagnose the problem. Make sure that you are using the latest driver and firmware for your network cards and routers. Also try to force the network card to use 100Mbs/Full Duplex instead of the 'Detect automatically the best speed settings'. In case of miscommunication with the router or other network device the automatic settings could be set in an inappropriate way and have huge consecuencies on the network performances.
Problem ID: 2782
Problem Description: How to run a scenario at a specific (absolute) time
How can the user execute a scenario at a specific (absolute) time in the day (e.g., 8pm) instead of using a relative "time from now."
________________________________________
Solution: Use scenario scheduler of Controller or Windows Scheduler
Using Scenario Scheduler of Controller:
1. Open the scenario in the Controller.
2. Go to Design Tab -> Edit Schedule -> Scenario Start time and set the time when you want to start the scenario.
3. You need to click on Start Scenario button so that the Controller can trigger the scenario once the start time comes up.
Using Windows Scheduler:
Scenario Scheduler of Controller is limited to the effect that it can only be sheduled to be run at one time. In order to re-run it the scenario has to be edited again. Instead, you can do the following:
1. You can have the scenario run from command line in a batch file as per Problem ID 13352 - How to run a scenario from the command line(Controller's Command Line Arguments).
2. Then you schedule this batch file to run at different times from the Windows Scheduler.
Problem ID: 15478
Problem Description: Setting scenario start time in LoadRunner does not work
In the LoadRunner Controller, under Scenario menu -> Start time, the scenario start time is set to a specific time. However, the LoadRunner scenario does not start at the set time.
________________________________________
Solution: Click on "Start Scenario"
After setting up the scenario start time, click on the "Start Scenario" button in the Controller. A pop-up menu will come up showing the count down to the start time the scenario.
Problem ID: 15717
Problem Description: Wlrun.exe does not close when executing a scenario via command line option
When executing a scenario via the command line option
wlrun -TestPath D:\temp\testscenario.lrs -ResultName "D:\temp\res" -Run
even if the Controller GUI interface has disappeared, wlrun.exe seems to continue to run for sometime.
________________________________________
Solution: Wlrun.exe shuts down after a delay
Depending on the scenario setting and results, wlrun.exe might take a longer time to shut down. There have been cases seen where wlrun.exe shutdowns 5-10 minutes after the Controller GUI interface disappears.
************************************************************************
Problem ID: 9277
Problem Description: How to read in string/text content from the command line in the Controller
How can the user get string or text information from the command line?
Example:
Command line parameter: -host
Value : server
This command line is entered as -host server in the Controller's command line text box. How can the user capture the value "server" and use it as a string in the script?
________________________________________
Solution: Use lr_save_string(lr_get_attrib_string("host"), "server");
You can capture the value for "server" using the lr_get_attrib_string() function.
Example:
lr_save_string(lr_get_attrib_string("host"), "server");
The lr_get_attrib_string() function will capture the string "server" from the command line, and the lr_save_string() function will insert the value into a parameter called [server].
Problem ID: 22476
Problem Description: Running LR from the command line does not collate results from a remote machine
LoadRunner is not collating the results from a remote Load Generator machine when running from the command line.
Note:
The user is running LoadRunner 7.51 SP1.
________________________________________
Solution: Contact Customer Support for Patch LR751SP1P17
Please contact Mercury Customer Support for Patch LR751SP1P17 - LoadRunner 7.51 SP1 Fixes several bugs in launching Controller through command line.
Problem ID: 16855
Problem Description: How to modify the heartbeat time-out
When starting a scenario and connecting to the remote host, the Controller machine's CPU reaches 100% and its user interface freezes.
Diagnosis: This could happen if there are a lot of remote hosts (several hundreds) or when there are large data files to be transferred.
________________________________________
Solution: Minimize heartbeat frequency so the hosts will send less heartbeat messages to the Controller
In LoadRunner, all hosts manage heartbeat mechanisms with the Controller. By default, each host sends four messages in two minutes with frequency of 30 seconds until heartbeat failure is reached. This could cause a problem when there are a lot of hosts or large data files.
To work around the issue, you need to minimize the heartbeat frequency so that the hosts will send less heartbeat messages to the Controller. Since LoadRunner waits time-out*4 before it reaches heartbeat failure, you can increase the time-out value of the Controller and Load Generator machines (so as to minimize the frequency) or minimize the heartbeat messages.
To minimize the heartbeat messages:
1. Close the Controller, and stop the LoadRunner Agent process/service.
2. Modify the mdrv.dat file in the
3. Add the following lines to the end of [Launcher] section:
ExtCmdLine= -HB_TIMEOUT
ExtCmdLine= -HB_TIMEOUT_LIMIT
Example:
[Launcher] ExtPriorityType=launcher WINNT_EXT_LIBS=launcher.dll WIN95_EXT_LIBS=launcher.dll LINUX_EXT_LIBS=liblauncher.so SOLARIS_EXT_LIBS=liblauncher.so HPUX_EXT_LIBS=liblauncher.sl AIX_EXT_LIBS=liblauncher.so LibCfgFunc=launchext_configure UtilityExt=two_way_comm ExtMessageQueue=0 SecurityMode=On ExtCmdLine= -HB_TIMEOUT 120000 ExtCmdLine= -HB_TIMEOUT_LIMIT 5
Note:
• The "-HB_TIMEOUT 120000" option sets the time-out to send heartbeat messages every 120 seconds.
• The "=-HB_TIMEOUT_LIMIT 5" option sets the number of times to resend heartbeat messages to 5.
4. Repeat steps 2-3 for the mdrv.dat file in
Note:
If you change the heartbeat to be every 2 minutes, the Controller will be able to establish a connection, however since the hosts still send heartbeat messages it cause the UI to get stuck every 2 minutes for half minute.
Problem ID: 3709
Problem Description: How to set the "Save as" directory opened by VuGen or Controller
When doing a "Save as," is it possible to specify which directory is brought up by default in VuGen and the Controller?
________________________________________
Solution: Defining the default directory for VuGen and the Controller
To change the default directory that comes up, modify the following file entries:
For VuGen
In the "vugen.ini" file located in the WinNT directory.
[General]
LastScriptPath=D:\TEMP\scriptname
For the Controller
In the WinNT directory, there is the configuration file for the Controller. It is called wlrunX.ini where X is a number that changes depending on the version of the Controller used. For LoadRunner 6.x, the file is called wlrun5.ini. For LoadRunner 7.x and higher it is wlrun7.ini.
[General]
DefaultScenarioDir=D:\TEMP\scenario_name.lrs
Problem ID: 10315
Problem Description: Cannot connect to the host machine from the Controller
Diagnosis: AOL is installed on the machine.
________________________________________
Solution: Cannot have AOL and the Controller on the same machine
LoadRunner conflicts with AOL. You cannot use AOL and the Controller on the same machine.
Here is the work-around that you can try:
Steps to disable "AOL - WAN Network Driver"
1. Right-click on the "My network places" icon on the desktop, then click on "Properties."
2. Right-click on "Local Area Connection" (for AOL), then click on "Disable."
3. Only after this, try to launch the Controller and connect.
Problem ID: 17845
Problem Description: Can the user run multiple Controllers using a network installation
How does a network installation work? Is it possible to access the Controller from multiple workstations if a network installation is done on the server and workstation installation is done on each individual workstation?
________________________________________
Solution: Purchase multiple Controller licenses to run multiple Controllers
Network installations allow for installing all the setup files for various LoadRunner components on a shared network drive of a server. A corresponding workstation installation will create LoadRunner program group on each workstation. This will aid in saving lots of disk space on the local machine and a global update facility for any kind of patches and upgrades. However, the Controller workstation has to be pre-determined as a license needs to be installed on the local workstation only and not on the shared network drive of the server where network installation is done. This means Controller is still a single workstation and will not be running on all workstations. You need to purchase multiple Controller licenses to run multiple Controllers.
Problem ID: 11422
Problem Description: Can different versions of LoadRunner be used together in a scenario
Can different versions of LoadRunner be used together in the same scenario?
Example:
Controller Version: LoadRunner 7.5
Host Version: LoadRunner 7.51
________________________________________
Solution: The same version of LoadRunner must be on all machines in a scenario
Because the communications protocol is constantly being updated between versions (even minor versions), you have to ensure that all machines being used are on the exact same version of LoadRunner. This goes for any patches installed as well.
Example:
If the Controller is on LoadRunner 7.51 with xxx patch, the hosts have to be on LoadRunner 7.51 with xxx patch.
Problem ID: 11369
Problem Description: How to enter a new license key for LoadRunner
How to enter the new license key in LoadRunner when LoadRunner is already installed.
________________________________________
Solution: Steps to add a new license when LoadRunner is already installed
Follow the steps below to add/update LoadRunner license key on an existing install:
For LoadRunner 8.1:
1. Close the Controller
2. Go to Start -> Programs -> LoadRunner -> LoadRunner -> Configuration
3. Click on the "License" menu
4. Click on "New License" and type in the new license key
5. Click
6. Bring up the Controller again.
For LoadRunner 8.0:
1. Close the Controller
2. Go to Start -> Programs -> LoadRunner -> LoadRunner
3. Click on the "License" menu
4. Click on "New License" and type in the new license key
5. Click
6. Bring up the Controller again.
For LoadRunner7.0 - 7.8 Feature Pack1
1. Bring up the Controller and go to Help -> About LoadRunner.
2. Click on "New License" and type in the new license key.
3. Click
4. Close the Controller and restart it; the new license key will be in effect
Problem ID: 23086
Problem Description: How to configure the Controller to open different versions of Analysis
The Analysis tool can be launched directly from the Controller by clicking on Tools -> Analysis. How can the user configure the Controller so it launches a different version of Analysis tool installed on the same machine as a stand-alone component?
________________________________________
Solution: Configure AnalysisPath in wlrun7.ini to point to the desired path
1. Go to the C:\Winnt directory and open the wlrun7.ini file.
2. Find the [Tools] section.
3. Add or modify the AnalysisPath entry so that it points to the desired installation of Analysis.
Example:
[Tools]
AutoAnalysis=0
AnalysisPath=
Problem ID: 24730
Problem Description: Accessing the Output window in the Controller increases the size of output.mdb
Accessing the Output window in the Controller increases the size of output.mdb in the result folder.
Example:
The user ran a scenario that output x number of messages. If the user does not access the output window in the Controller during scenario execution, the size of output.mdb is relatively small. However, if the user accesses the output window, the size of output.mdb could double or triple in size.
Diagnosis:The MS Access database (.mdb) is updated each time the Output window is accessed. If the user accesses the output.mdb file after the scenario, he will see that MS Access actually creates new views and temporary tables to display the data while he accesses the Output window. The temprorary views and tables is the cause of the size differences.
________________________________________
Solution: Compact and repair the database
To reduce the size of output.mdb so that it is the same with a scenario where the Output window in the Controller was not accessed, you need to compact and repair the database.
1. Open the output.mdb file in MS Access 2000 or MS Access 97 .
2. Go to Tools -> Database Utilities -> Compact and Repair Database.
For LoadRunner 7.51 SP 1 or above, there is an option to print output messages to a text file instead of the Access database. For further information, refer to Problem ID 15075 - How to send the Controller output information to a file instead of viewing it from Controller itself.
************************************************************************
Problem ID: 16965
Problem Description: Some Vusers do not wait for other Vusers at the rendezvous point
The user created a script with a rendezvous point set. When replaying it in the Controller, the Vusers do not wait for other Vusers. LoadRunner Vusers sometime exit the rendezvous point even though not all Vusers have arrived.
________________________________________
Solution: Increase the timeout between Vusers
The LoadRunner rendezvous point will timeout after 30 seconds by default. This means the Vusers will continue running if either of the following conditions apply:
• All the users have reached the rendezvous point, or
• 30 seconds has passed.
If you would like to change the conditions, so that Vusers exit the rendezvous point only when 100% of the Vusers reach the rendezvous point, do the following:
1. In the Scenario, go to Scenario -> Rendezvous.
2. Highlight the rendezvous name and select "Policy."
3. Select the relevant settings, and verify that you increased the timeout (so that timeout will not occur).
Again, you need to set the value for timeout between Vusers to be high enough so that timeout will not happen before all Vusers reach the rendezvous point.
Problem ID: 16971
Problem Description: C++ run-time error when running a Scenario
When trying to run a scenario, the following error comes up as a pop-up window:
"Assertion failed!
Program:....s\Mercury Interactive\LoadRunner\bin\wlrun.exe
File:S:\EventServer03\nt\app\EsDll\ESEngin.cpp
Line:90
Expression: Gran>=1"
Diagnosis:This error might appear if there is a problem with the LoadRunner installation.
________________________________________
Solution: Verify the LoadRunner installation
There are many reasons that can lead to the problem above. Things you can verify includes:
1. Make sure that LoadRunner was installed with a local administrator account.
2. Verify that you are logged into the machine as the local administrator.
3. Go to C:\winnt folder and delete: wlrun.ini, wlrun5.ini and wlrun7.ini.
4. Go to
5. The assertion errors can also occur due to a corrupted scenario. If you are using saved scenario file, try to create a new scenario and run the test.
Problem ID: 17136
Problem Description: Scenario scheduler does not ramp down at the specified time
After setting up a schedule for LoadRunner Vusers to ramp up and ramp down after certain duration, the scenario does not stop at the specified time.
________________________________________
Solution: Verify the Vuser stop behavior
The Vuser stop behavior will affect the time when the scenario ends. To verify the Vuser stop behavior:
1. From Controller, go to Tools -> Options -> Run-Time Settings
2. The available stop options include:
a. Wait for the current iteration to end before stopping
b. Wait for the current action to end before stopping
c. Stop Immediately
Install Patch LR75P22 scheduler ramp
Problem ID: 26817
Problem Description: How to show more than 20 measurements in the Controller online monitor
By default, the Controller online monitor only shows 20 measurements for each graph. Additional measurements enabled will be in the "hidden" option. Is there any way to increase this?
________________________________________
Solution: Modify the value of MaxDispMeasurments
You can enable the Controller online monitor to display more than 20 measurements for selected categories of graphs.
Example:
• System Resource Graphs
• Runtime Graphs
• Transaction Graphs
• Web Resource Graphs
• Streaming Media
To display more than 20 measurements:
1. Go to the
2. Open the relevant .def files using word editor:
System Resource Graphs - online_resource_graphs.rmd
Runtime Graphs - online_runtime_graphs.def
Transaction Graphs - online_transaction_graphs.def
Web Resource Graphs - online_web_graphs.def
Streaming Media - online_web_graphs_mms.def
3. Locate the monitor for which you want to display more than 20 measurements.
4. Modify the value of MaxDispMeasurments=.
Example:
To display 30 Measurements for the Windows Resources Monitor:
1. Open online_resource_graphs.rmd from
2. Locate the ;--- Windows Resources --- section.
3. Change the value of MaxDispMeasurments= to 30.
Example:
MaxDispMeasurments=30
Modify the value of MaxDispMeasurments 1-14689s
5. Suggested debugging steps if Controller crashes
Make sure that you login as a local administrator
Login to the Controller machine with a local administrator account. Currently, Mercury do not support running Controller using a domain account. Using domain account may cause unexpected behaviors.
Make sure that there are sufficient Disk Space
Make sure that you have enough disk space available on the controller and load generators. During scenario execution, the events are written onto the Load Generator machines and are saved locally until the scenario finished; where results are send back to the Controller. If the machine does not have enough disk space, it can cause problem.
Check if the size of the output.mdb file in the results folder is more than 2 GB
If the output.mdb file becomes greater than 2GB during a load test, Controller is unable to write into it anymore and cause a crash. If the size of output.mdb file is larger than 2 GB, divert the output to a text file as per Problem ID 15075 - How to send the Controller output information to a file instead of viewing it from Controller itself
Run the Controller’s batch files to register DLLs
Sometimes, DLLs can become unregistered or the registry can become corrupted to a point where a program's DLLs cannot be found. The purpose of batch files is to reregister them into the system's registry so that the programs can locate them. Use the following steps to do this:
1. Shut down the Controller.
2. Navigate to the
• register_controller.bat
• set_mon.bat
3. Create a duplicate copy of the file, in the same location.
4. Open up the duplicated file. In it, you should see several entries like the following:
regsvr32 /s webbrwsr.dll
Remove the "/s" from each of these statements, but leave a space between the "regsvr32" and the DLL name.
5. Save the changes.
6. Double click on the batch file to run it. You should get several pop-up messages similar to the following:
Note: You could get failure messages for escomps.dll and resmonps.dll. You can safely igonore these errors. But you should not get any other failure messages. If you do, then that DLL is the problem file. Try registering this from the command prompt:
Example: regsvr32 < LoadRunner >\bin\
If this does not work, try copying the DLL from the CD or ask support for the DLL to try registering it manually. Retry the same action that caused the error.
Verify the CPU usage on the machine
Verify the CPU usage on the machines. Ideally, they should be below 80% usages. If necessary, distribute the Vuser load to other machines.
Try to recreate the Controller’s initialization file
Sometimes, the initialization files can become corrupted (e.g. after a crashed). You will have problem in launching or using the Controller after that. Use the following steps to do delete the initialization file so that a new copy will be created:
1. Shut the Controller.
2. Navigate to the C:\Winnt ( or C:\Windows for Windows XP machine )
3. Delete all files that begin with wlrun*. For example,
wlrun.ini, wlrun5.ini, wlrun7.dft, wlrun7.hst, wlrun7.ini
Check the temporary environment variables
Unlike the earlier window’s versions, Window 2000 and Window XP have the default environment set to c:\Document and Settings\
Verify if Hyper Threading is enabled
Verify if Hyper Threading is enabled. If so, you will need to disable it. LoadRunner does NOT support Intel Hyper-Threading technology. Hyper-Threading can be disabled in the BIOS. For more information, refer to
http://www.microsoft.com/windows2000/docs/hyperthreading.doc.
Verify the MDAC version
Make sure that you have MDAC 2.6 or higher installed. You can find the MDAC version on your machine by referring to the information on Microsoft Knowledge Base Article 301202 - HOW TO: Check for MDAC Version. You can download the latest MDAC version from MDAC Downloads
Reboot
When programs crash, they leave the system in an unstable state. This can cause many other problems that seem to have no apparent reason for happening or has not happened before. When the system is rebooted, it resets the system into a more stable state. This should be done after any program crashes.
Verify the information in the event viewer
Sometimes, if a program crashes, it does not give any clues for what had happened. By using the Windows event viewer, it may be possible to find some clue as to what happened when the crash occurred. The event viewer can be launched from Start Programs Administrative Tools Event Viewer.
Verify other programs are interfering with Controller
To find out whether hooked DLLs are possibly causing a problem, you can use a third party utility call "Process Explorer." This utility has the ability to view the DLLs loaded by an application. It can be downloaded free of charge from the following link:
http://www.sysinternals.com/ntw2k/freeware/procexp.shtml
This can be used to see if LoadRunner loaded any other program's DLLs. Use the following steps to do this:
1. Unzip the .zip file, which was downloaded from the above URL, into a directory where you wish to install Process Explorer.
2. Start the Controller.
3. Run the Process Explorer (procexp.exe) from the directory into which you unzipped it (step a).
4. Select wlrun.exe (Controller) from the top section of Process Explorer.
5. The bottom section should be displaying a list of DLLs. If it is showing handles for the application, go to the "View" menu and select "DLLs." It should look like the screenshot below:
6. Search through the list to see if any other program's DLLs are loaded. Normally, only DLLs from the
Shut down all unnecessary processes
Some programs are designed to have certain DLLs "hook" or be loaded into another program's memory space. Normally, this should not have any effect on the application itself. However, it can interfere with some programs and cause them to behave erratically or crash. (Verify if there are other programs that interfering with Controller )
For such, it would be recommended to shut down all processes that are not necessary, regardless if they hook into LoadRunner or not. Any programs that run as an icon in the system tray or on the taskbar are the first candidates for termination. Also, you can look through the list of processes in the Task Manager (right-click on the taskbar and select "Task Manager"). Some processes are system processes, which may not be able to be shut off, but any processes that can be shut down should be.
Disable anti-virus software
It is known that anti-virus software is intrusive when they are set to look for viruses. However, in searching for viruses, the software can interfere with a program's proper execution. This could cause problems and sometimes crashes. This is why, for debugging purposes, we would recommend turning off the anti-virus software.
The icon for the anti-virus software resides in the system tray (where the clock is located). Normally, you should be able to right-click on the icon and select "disable." However, some setups do not allow a user to turn off the anti-virus software. It is recommended to speak to a system administrator to get the anti-virus program disabled for a short period for debugging the problem.
(Verify if there are other programs that interfering with Controller )
Reinstall
In case that all the above steps fail, the only recourse left would be to try to uninstall LoadRunner. It is possible that either a previous version of LoadRunner was on the machine before the current installation or that the installation did not go properly although the installation did not give any errors. It is recommended that a full uninstall be done in this case. The following steps are for a full uninstall:
1. Make sure that, all running LoadRunner processes (including the Controller, VuGen, Analysis and the Remote Command Launcher (for 6.x) or the LoadRunner Agent Process/Service (for 7.x) are closed.
2. Backup any existing scripts that may have been saved in the LoadRunner installation folder (The scripts are sometimes saved in a 'scripts' subdirectory under the LoadRunner installation folder.).
3. Run the uninstall program from the LoadRunner program group (or) use the Windows add/remove programs from the Control Panel. If any prompt is given about removing shared files, remove all the shared dlls that are reported as no longer being in use. In the very rare instance this causes a problem for some other application it may be necessary to re-install that other app. This is not generally a problem because every application should have registered which DLLs it needs to run.
4. Reboot the machine after the Uninstall wizard is complete. This will complete the basic uninstall procedure.
5. Delete all LoadRunner Folders. (Including the ones in the start up menu for Remote Command Launcher (LoadRunner 6.x) or Agent Process (LoadRunner 7.x)
6. If the installation is LoadRunner 6.x then delete the Borland Folder (Usually in c:\Borland or c:\BDE).
7. Do a search for the following files and remove them from all locations -- they will be replaced during the re-install.
a. wlrun.*
b. vugen.*
8. Bring up the registry editor: (Start Run regedit).
9. Delete the following keys:
a. Only for LoadRunner 6.x
HKEY_LOCAL_MACHINE\SOFTWARE\BORLAND
b. If Load Runner is the only Mercury Interactive product on this machine, then delete
HKEY_LOCAL_MACHINE\SOFTWARE\Mercury Interactive.
HKEY_CURRENT_USER\SOFTWARE\Mercury Interactive.
c. Else delete
HKEY_LOCAL_MACHINE\SOFTWARE\Mercury Interactive\LoadRunner.
HKEY_CURRENT_USER\SOFTWARE\Mercury Interactive\LoadRunner.
10. Empty the Recycle-bin.
After you remove these items, you can re-install LoadRunner. Also, make sure that you do not have any anti-virus programs running while you are installing LoadRunner. That has been known to cause some problems with the installation of LoadRunner.
NOTE: Reinstallation should only be done for the following certain circumstances.
1. The crash only happens on a particular machine.
2. Some feature that was previously working is now crashing.
3. The above options were tried before hand.
Modify the heartbeat timeout
In LoadRunner, all hosts manage heartbeat mechanisms with the Controller. By default, each host sends four messages in two minutes with frequency of 30 seconds until heartbeat failure is reached. This could cause a problem when there are a lot of hosts or large data files.
To work around the issue, you need to minimize the heartbeat frequency so that the hosts will send less heartbeat messages to the Controller. Since LoadRunner waits time-out*4 before it reaches heartbeat failure, you can increase the time-out value of the Controller and Load Generator machines (so as to minimize the frequency) or minimize the heartbeat messages.
To minimize the heartbeat messages:
1. Close the Controller, and stop the LoadRunner Agent process/service.
2. Modify the mdrv.dat file in the
3. Add the following lines to the end of [Launcher] section:
ExtCmdLine= -HB_TIMEOUT
ExtCmdLine= -HB_TIMEOUT_LIMIT
Example:
[Launcher] ExtPriorityType=launcher WINNT_EXT_LIBS=launcher.dll WIN95_EXT_LIBS=launcher.dll LINUX_EXT_LIBS=liblauncher.so SOLARIS_EXT_LIBS=liblauncher.so HPUX_EXT_LIBS=liblauncher.sl AIX_EXT_LIBS=liblauncher.so LibCfgFunc=launchext_configure UtilityExt=two_way_comm ExtMessageQueue=0 SecurityMode=On ExtCmdLine= -HB_TIMEOUT 120000 ExtCmdLine= -HB_TIMEOUT_LIMIT 5
Note:
• The "-HB_TIMEOUT 120000" option sets the time-out to send heartbeat messages every 120 seconds.
• The "=-HB_TIMEOUT_LIMIT 5" option sets the number of times to resend heartbeat messages to 5.
4. Repeat steps 2-3 for the mdrv.dat file in
Note:
If you change the heartbeat to be every 2 minutes, the Controller will be able to establish a connection, however since the hosts still send heartbeat messages it cause the UI to get stuck every 2 minutes for half minute.
Make sure that there are sufficient memory available
To check available memory on a machine:
Right-click the status bar, and select Task Manager. Select the Performance tab to check the physical memory available. Select the Processes tab to check which processes have high memory consumption in the CPU column.
To free up memory:
• Close any unnecessary processes running on the machine, and try running the scenario again.
• Restart your computer.
• If the problem persists, reduce the number of virtual users that you are running on the same machine.
To enlarge the size of your virtual memory:
1. Click Start -> Settings -> Control Panel -> System.
a. For Windows 2000, select the Advanced tab, and click Performance Options.
b. For Windows NT, select the Performance tab.
2. In the Virtual memory section, click Change.
3. In the Drive list, click the drive that contains the paging file you want to change.
Under Paging file size for selected drive, type a new paging file size in megabytes in the Maximum size (MB) box, and then click Set.
To boost performance, and allow more Virtual Users to run on the load generator machine:
• On Windows 2000 machines, select Start -> Settings -> Control Panel -> System -> Advanced -> Performance Options, and select the Background Services option.
On Windows NT machines, select Start -> Settings -> Control Panel -> System Properties > Application Performance. S
No comments:
Post a Comment