• Document ID 31731: Troubleshooting guide for VuGen (not stable/crashes/freezes/GPF)
• Document ID 12532: Troubleshooting guide for Controller ( not stable/crashes/freezes/GPF )

There are a couple of solutions in both documents, but we would recommend trying out the following that usually resolves the problem.

• Login as administrator and perform the work with that account.
• Run the batch file.
• Reinitializing the .ini file or the document term it as “recreate the initialization file”.

Take note on the terminology of the administrator here, it is the default administrator account on the Windows operating system without any changes to it’s roles or privileges. If the environment you worked in have default images, or amended administrator account, you may need to use a machine that is “clean” to test out and run Vugen or Controller. On top of the given list from the official vendor, we’ve experiences that certain situations may cause the Vugen and Controller to behave abnormally as well.

Do you have another Mercury/HP product running on the same machine such as QTP or WinRunner? They may conflict with Vugen and Controller when placed together on the same machine. As such, it is advisable to install only LoadRunner components on the machine while other products are to be installed separately.

In addition, you can use Process Explorer (as recommended by the document) to find out if there are conflict with the processes. The link is broken in the document as Sysinternals have been acquired by Microsoft in July 2006. Click Process Explorer to be directed to the actual website.

Do you have DEP enabled in your machine? DEP (Data Execution Prevention) is part of the Windows XP SP2 feature and extends to Windows 2003 and the Vista versions. For more information of DEP, refer to the following resources:

• A detailed description of the Data Execution Prevention (DEP) feature in Windows XP Service Pack 2, Windows XP Tablet PC Edition 2005, and Windows Server 2003
• Data Execution Prevention by Wikipedia
• Data Execution Prevention by Marc Liron

To resolve this problem, you have to disable DEP. This is as described in Document ID 41489: No events recorded in VuGen when trying to record an application on Windows 2003 SP1 or Windows XP SP2.

What are the technology/protocol used by the application? Specified to Vugen recording, the third possibility that causes the problem is the type of application that you are working with. Example, if the application runs on RCP (Rich Client Platform) or applets but communicates in HTTP. For this, you’ve to identify the actual protocol being transmitted and find workarounds to it. In the example of HTTP, you can refer to a previous article, “Quick-and-Dirty Recording Techniques for Web (HTTP/HTML)” for more information.

If all else fails, the best suggestion is to get a “clean” machine, login with the default local administrator and perform a re-installation of LoadRunner. Remember, the definition of “clean” means that the machine operating system is not based on a clone image. Well, we’ve to say that this is not the entire list that the community is experiencing and therefore, if you have a problem relating to the crashing or abnormal behavior, please share with us and we will append to this list accordingly.

Mercury/HP Support have provided some information on this particular topic in Document ID 3803 – Nothing gets recorded while performing some client side activity and Document ID 42319 – VuGen is not replaying the rendering of an Excel file in the browser’s MS Excel plug-in. In both articles, it just merely describes what is client side activity and it cannot be recorded. (Take note that you required a valid login to the support website to access the article.)

At the release of LR 8.1 FP3, a new protocol called Web (Click & Script) was introduced. Document ID 48261 – New Features/Enhancements for the Web Click and Script protocol in LoadRunner 8.1 Feature Pack 4 provides more details in it as an enhanced released of FP4. This protocol “promises” that the scripting will be make easy and it will resolve some of the client-side activities such as Javascripts. However, to my experience, I wasn’t successful in using it (or maybe I missed out some steps concerning this new protocol)… anyway… you can give it a try in recording those web applications with Javascripts/AJAX or similar components embedded into the web application (if you have intentions in recording the client-side activities). I would be more concerned with actual load been generated to the SUT and will use the conventional Web (HTTP/HTML). Similarly, there is an AJAX protocol that was introduced in LR 9 to record AJAX applications.

Having the concept in mind, I would like to go a little further with the following example.

For activities such as, opening of file, editing in Excel sheet, or bat files performing copying operations are considered to be client-side activities. Think about it, do they generate any network traffic (unless you the activities really have a network call to a remote server)?

Another example is that if a web application allows opening of files such as documents over the browser (e.g. Sharepoint). The underlying mechanism for the file opening operation still requires a client installation of the program (e.g. MS Word), and subsequent activities are done locally on the client machine even though it exist in a browser. This of course is also considered as a client-side activity.

So, before recording the application, please ensure that you know the functionality of the Business Process that you are recording and determine if it is a client or server activity. This will greatly reduce the unneccessary effort in scripting and later realizing that it is client activity. If it is a client activity, a no-go, wrong tool for the job! It served no purpose of the tool to conduct non-performance tests. Consider other tools such as Quick Test Professional or Silk Test for functional testing client-activities.

What are the possibilities in Vugen?

1. The application that you are replaying against is not running.

Simple? But it does happen, as such, when it fails on replay, take some time and try logging into the application manually and perform the business processes.

2. There were changes to the application

There were changes to the application in aspect that had affected the script. For a 3-tier architecture, anything could have changed such as the following:

a. Presentation layer: where links or button are removed,
b. Application layer: where methods are changed or removed,
c. Database layer: where calls or tables are changed or removed.
d. Architecture level: where proxies or load balancers are changed or
removed.

As such, verify with the application and infrastructure team if there were any changes made. You may have to re-script or amend the script accordingly to the changes.

3. There are dynamic values that needs to be correlated.

This is common in applications. They are usually in the form of Session IDs or returned values based on parameterization. You have two options here:

• Use the auto-correlation feature to detect any dynamic values (which I don’t usually use) or,
• Perform manual correlation by recording two scripts of the same business process. From the two scripts, compare the recording logs and the APIs that had been generated for the differences. If you are new to manual correlation, I would recommend you to go through Document ID 11806 – What is correlation and how is it done from the support website to get a better understanding.

4. The parameterization may be causing the problem

The parameterization may be causing the problem in the following manner:

• Insufficient records: ensure that you have sufficient records for the replay, especially in iterations.
• Incorrect records: verify with the application or database team that you are holding on the valid values to be passed in as parameters. Parameterization may also result in different set of data being returned by the server as mentioned previously in (3). If that happens, correlate the value accordingly.

For (1) to (4), it’s recommended to turn on Full Extended Log (all options enabled: Advanced Trace, Parameter Subsitution, Data Returned From Server) in the Runtime Settings (Vugen) to verify the data that is been transmitted between the server and the client (script). Through this, you can find out what and where that could have gone wrong in the replay.

What are the possibilities in Controller?

5. Does it happen at the start of the scenario execution?

We are focusing on the script only and leaving out the load testing setups. If the script/vuser fail at the start of the execution, verify the script again in Vugen, and if it still fails; it’s a script problem where you have to re-work from the previous point (1) to (4).

6. Does it fail on a particular Load Generator (LG)?

This maybe caused by inconsistent LG across the load testing environment. As such, ensure the following in order for the script to run properly (but not limited to the list):

• Folder directories that the script may be accessing to (particularly for file upload and download business processes).
• Java settings like JVM and CLASSPATHs that can affect Java LoadRunner scripts.
• All LGs have the same version as the Controller (e.g. LR9.0 across all LGs in the load testing environment).

7. Does it happen at the middle of the scenario execution?

If it is the case, it maybe caused by anything but unlikely script problems (since the script/vuser have already started running successfully at the start of the run in (5). When this happens, the Application Under Test (AUT) maybe under load and unable to process all requests from the scripts/vusers and therefore returning errors to them. You can verify this with the following.

• Manually log into your AUT again and verify if it is still running or experiencing any lags.
• Reduce the amount of vusers being generated in the scenario and re-run the test. If a reduced amount results in a error-free or non-script related errors, you are sure that the AUT is under load.

The above should be sufficient for you to troubleshoot script/vuser problems in Vugen and Controller. However, take note that it may not be limited to those and it will be advisable to carefully work the problem step-by-step to eliminate and possibilities.

[1] Think Time

Think time is as recorded during the recording of the application. During the recording, you maybe entering values into the text fields, or browsing through your data sheet or maybe thinking of something (whatever…), all these will be recorded and generate as a LoadRunner API, lr_think_time.

In your Script-view, for example you should see it as lr_think_time(90) if you had used 90secs to perform a task such as entering values into an online form. To change the value, simply change the value in lr_think_time(90) to lr_think_time(60) which means you are changing the value frm 90secs to 60secs. This is the same in the Tree-view. That is to change the value for Think Time.

You can further manipulate how the Think Time will be replayed in the Run-Time Settings.

You can choose the following options to suit your needs.

1. Ignore think time
2. Replay think time as recorded
3. Multiply recorded think time by
4. Use random percentage of recorded think time

Ignore think time

Your script is going to run like a robot where there is no delay between each form submission. Not possible for a real human to do that which makes the load test unreal.

Replay think time as recorded

This setting will cause the script to replay as it is. It looks all good in Vugen at first but when you are in the Controller, it looks weird as all vusers will be replaying at the same amount of think time, which again, looked like cloned robots. If you have transactions created for the script, in the Controller graphs, all transactions will perform at the same speed.

Multiply recorded think time by

Straight-foward description; this setting multiplies the recorded value with the numeral provided, extending the time delay in the script.

Use random percentage of recorded think time

Personally, I like to use this option where the script will replay the percentage range of the recorded think time. With the recorded think time, I allow 50% – 150% deviation emulating the expert users (lower range:50%) and novice users (upper range:150%). I presumed the speed I’m working (recording) with the application is at an average user speed.

Limit think time to

This last option allows the script to replay the think time at a defined minimal limit.

[2] Pacing

Pacing is the interval between each iterations which defines the time the script waits between iterations of actions. Below is the screenshot of the Pacing options in the Runtime Settings launched from Vugen.(click on image to enlarge)

You can choose the following options to suit your needs.

1. As soon as the previous iteration ends
2. After the previous iteration ends with a fixed or random delay of ..
3. At fixed/random intervals, every …

As soon as the previous iteration ends

The default setting in Vugen. The next iteration will start without any delay after the current iteration ends. The following illustrates the setting better.(click on image to enlarge)

After the previous iteration ends with a fixed or random delay of ...

This setting will start the next iteration after the current iteration ends and with the defined delay (setting) achieved. This interval can be either fixed or random and applies for all iterations. The following illustrates the setting better. (click on image to enlarge)

At fixed/random intervals, every …

This setting will start the next iteration based on the start of the previous iterations. For example you defined 30secs as the interval, the iteration completes in 12secs in the 30secs timeframe, then the next iteration will start after 18secs. Note, the scheduled iterations will only begin when the previous iteration is complete. The following illustrates the setting better.(click on image to enlarge)

[3] Action blocks

Action blocks are groups of actions within the vuser script. Actually you can think of it as two components. One, is the action which is defined in the script and two, the block that holds the actions. As mentioned earlier in previous article, Configuring Real User Behavior in LoadRunner – Time, the purpose of action blocks allowed the tester to define a modular action of the real user.

What can you do with the action blocks:

1. The actions to be included in a block
2. The sequence of the actions in a block
3. The number of iterations that the block will run

Below illustrates the Run-time Settings for the Run Logic. (Click on the image to enlarge it).

Let’s discuss a little more on this action blocks. For the actions, actually you can’t do much with it except to choose it from the list of actions available in the script and then place it in your desired block. Most of the settings are on the block itself.

Note:
The “Run” is also consider a block with iterations of its own.

For the block, after you inserted one, you can provide the number of iterations for the block and include the actions that will be part of the block. Furthermore, you can define the block to perform either sequentially or randomly (via percentage parameter). This is all configurable at the block level, that’s to say, for each block, you can configure iterations, type of actions and sequence. Below illustrates the settings (click on the image to enlarge it).

Note:
Be careful when you delete a block, the actions in the block will also be removed!

[4] Iteration

What iteration does is to define the vusers to repeat a set of actions a specified number of times.

Previously mentioned in this article, iteration is configured on the block level. Take note that iteration is applicable to “Run” block (which is also applicable to blocks that are within the “Run” block). It is not applicable to “Init” and “End” block which is unlike insertion of actions in “Init” and “End” block that is applicable.

Note:
When the script is ported into Controller for load testing, the scenario scheduling settings will override the vuser iteration settings. This means that if the duration is set to the five minutes (default), the vusers will continue to run as many iterations as required until the five minute completes, even if the run-time settings in Vugen specifies one iteration only.

(Source: Vugen User Guide, Chapter 12, Configuring Run-Time Settings)

A good recommendation of using iteration other than for simulating an action performed multiple times is to ensure the parameter settings are working fine before proceeding with the scenario setup in the Controller.

Let’s go through a technical overview of what you need to do for it to work!

1. Get and install the database driver to connect to the database
2. Get the database connection string
3. Get the SQL statement for query
4. Create a new parameter using Database Query Wizard
5. Enter the connection string and the SQL statement

Now, let’s go through the details here with some screenshots to make it easier to understand.

[1] Download driver

I’ve obtained my MySQL-ODBC driver from MySQL website. You will need to find out what is the driver required to connect your database accordingly.

[2] Get the database connection string

In the context of MySQL database, I referred to ConnectionStrings. The string that I used was for 3.51 driver and I was trying out on a localhost MySQL which will looked like the below

Driver={MySQL ODBC 3.51 Driver};Server=localhost;Database=myDatabase; User=root;Password=rootpassword;Option=3;

Of course, you can refer to other type of connection string in ConnectionStrings.com as well! If you have tried out with other database, please let us know and we can compile them into a single source of reference point!

[3] Get the SQL statement

The SQL statement that I used was show status, which actually queries the status of MySQL database. Take note, I’m just using it for example purposes, you can use conventional statements like SELECT field FROM table.

[4] Create a new parameter using Database Query Wizard

In the script and create a new parameter using Database Query Wizard (Open Parameter list > New > Data Wizard > Select “Specify SQL statement manually” > click “Next”)

Database Query Wizard

[5] Enter the Connection String and SQL statement

Enter the Connection String and SQL statement, and click “Finish”. If the connection string and SQL statement are valid, after you clicked “Finish” the parameter should be populated accordingly.

Enter Connection String and SQL statement

Connection and query successful!

That’s it and done! Hope it helps you when you are using the Database Query Wizard! Do share with us if you have tried other databases with the Database Query Wizard!