Common Vuser Errors – Troubleshooting

1. Initialization Problems – Online Process Failed to Initialize: Failed to create Online  process. The online process has not been initialized. The online process has not been initialized.

Troubleshooting:

Check that the Controller COM objects are registered in the Registry Editor:  HKEY_LOCAL_MACHINE\SOFTWARE\Mercury Interactive\LoadRunner\CurrentVersion.

If they are not registered, run register_controller.bat from the <LoadRunner installation>\bin directory to register the COM objects.

If this fails to solve the problem, contact customer support and provide them with an explanation of the problem, and the error message returned.

2. Vuser Error – Unable to Activate Additional Vusers: LoadRunner Controller cannot activate additional Vusers. Ensure that your load generators are available and that your scripts are valid. Unable to activate additional. Possible causes: (i) Connectivity problems. (ii) Invalid script. (iii) Exceeding the number of licensed Vusers.

Troubleshooting:

Check that your load generators are available: Open the Load Generators window (Scenario > Load Generators), and check the status of the load generator specified in the error message to see if there is a connection to the host machine. If the host has been disconnected, reconnect and run the scenario again.

Check that each script is valid: Open each script in VuGen (View Script), and run the script (Vuser > Run). Check for any error messages in the Execution Log.

Check that your license supports the number of Vusers and script types that you are trying to run.

3. Vuser Error – Unable to Create Vusers: LoadRunner Controller cannot create Vusers. Ensure that your load generators are available and that your scripts are valid.

Troubleshooting:

Check that your load generators are available: Open the Load Generators window (Scenario > Load Generators), and check the status of the load generator specified in the error message to see if there is a connection to the host machine. If the host has been disconnected, reconnect and run the scenario again.

Check that each load generator does not exceed its Vuser limits: Open the Load Generators window (Scenario > Load Generators), click Details and select the Vuser Limits tab. Check that each load generator does not exceed the Vuser limits in the license.

Check that each script is valid: Open each script in VuGen (View Script), and run the script (Vuser > Run). Check for any error messages in the Execution Log.

4. Vuser Error – No Vusers in Scenario:

Troubleshooting: Add a script or group to the scenario: In the Design view of the Controller, click Add Group or Add Script(s), and select a group or script to add to the scenario. Run the scenario again.

5. Vuser Error – Vuser Type Unsupported:

Troubleshooting:

Check that the script you are trying to open is a LoadRunner script. Check your LoadRunner license to see which Vuser types are supported. If your version

of LoadRunner does not support this Vuser type, contact customer support to upgrade your version of LoadRunner.

How to enhance Vuser Scripts of LoadRunner

Once the recording of Vuser is done, then, next step is to enhance the capabilities of the script by adding some functions. Here, in this post, I’m going to describe some basic and most commonly used function categories in brief:

General Vuser Functions: The Vuser functions which have LR as prefix are general functions. These functions enhance the functionality of any Vuser Script to a great extent.

Protocol specific Vuser Functions: These are the library functions used to enhance the script.

Standard ANSI C functions: This is enhancing the Vuser script by adding general C functions like Adding Control statements, loops etc.

Inserting Transactions into Vuser Script: Inserting Rendezvous point and Inserting Comments etc.

Sending Messages to output: o For Log Messages – Lr_log_message o For Debug Messages – Lr_set_debug_message and Lr_debug_message o For Error and Output Messages – Lr_error_message and Lr_output_message

Handling errors on Vuser Script during execution: When an error is encountered by Vusers, the Vuser stops the execution of the script. The function lr_continue_on_error can be used to override the continue on error runtime setting. The statements lr_continue_on_error(1); and lr_continue_on_error(0) can be used to mark the segment.

Synchronizing Vuser Script: Synchronize applies only to RTE Vuser Scripts. The output from the application needs to be synchronized the execution of Vuser scripts.

Emulate Vuser Think Time: The function lr_think_time is used to emulate user think time. (The time that a Vuser waits between performing successive actions is known as the Think Time). Think time can also be set at run time settings.

Apart from the above mentioned functions / methods, there are two other importants methods / concepts: Parameterization and Correlation. I’ll explain these soon in my next posts.

Supported Environments by LoadRunner

Here is the descriptions of main environments and platforms supported by HP LoadRunner:

Application Deployment Solution: Citrix protocol Client – Server: MS SQL, ODBC, Oracle Web Applications 11i, DB2 CLI, Sybase

Ctlib, Sybase Dblib, Windows Sockets, and DNS protocols Custom: C templates, Visual Basic templates, Java templates, Javascript and VBScript

type scripts.

Distributed Components: COM / DCOM, Corba – Java, and RMI – Java protocols. E-Business: FTP, LDAP, Palm, Web (HTTP / HTML), Web Services, and the dual

Web / Winsocket protocols Enterprise Java Beans: EJB Testing and RMI – Java protocols ERP / CRM: Baan, Oracle NCA, Peoplesoft 8, Peoplesoft-Tuxedo, SAP-Web, SAPGUI,

SAP GUI / SAP – Web dual and Siebel (Siebel – DB2 CLI, Siebel – MSSQL, Siebel – Web, and Siebel – Oracle) protocols

Legacy: Terminal Emulation (RTE) Mailing Services: Internet Messaging (IMAP), MS Exchange (MAPI), SMTP and POP3 Streaming: MediaPlayer and RealPlayer protocols Wireless: i-Mode, Voice XML, and WAP protocols Platforms: NT, 2000, XP, Sun, HP, IBM, Linux

Apart from these environments, LoadRunner also supports the following environments:

Adobe Action Message Format, Adobe Real-time Messaging Protocol, Adobe Flex 2 and Flex 3, Ajax, C Vuser, Citrix ICA and XenApp v4.5, DB2 CLI, Domain Name System, Enterprise JavaBeans, HP WinRunner software, HP QuickTest Professional software, Internet Message Access Protocol, Jacada, Java Vuser, Javascript Vuser, Java Message Service, Microsoft Windows Sockets, SQL Server Informix, MQSeries-Client, MQSeries-Server, Multimedia Messaging Service, Palm, Oracle, VB.NET Template, VBNet Vuser, Wireless Application Protocol etc.

Best Practices for Performance Testing

Do’s:

After each performance test run, clear the logs for database and application. Large log files may result in inaccurate performance results.

To mirror the production environment, identify the correct software and hardware for server.

When a load is being generated on the system; to capture end user response time, use a single GUI client. If you need to generate load by using multiple client computers, you should consolidate data at single client computer / machine and generate results based on the average values.

During a load test, include a buffer time between the incremental increases of users. To create a more realistic load simulation, always Use different data parameters for each

simulated user. Never overly stress the client. Monitor all systems involved in the test including client

that generates the load. According to high volume transactions and critical functionalities, prioritize your

scenarios. If you need to fire concurrent requests, then, to identify bottleneck issues, use think time

as zero. Do stress testing for critical components of the system to assess their independent

thresholds.

Don’ts:

During load testing, never ever allow test system resources to cross resource threshold limits from a significant margin – Otherwise, it will distorts the data in your results.

For performance testing, always use an isolated test environment, but that environment should be exact replica of production environment. There should not be any other traffic load.

Do not put too much stress on the client test systems.

Transaction Response Time

Transaction Response Time – Time taken for the application to complete a transaction or business process.

Objective of measuring the Transaction Response Time – to ensure that the application is working perfectly under heavy load. However, the definition of heavy load may vary from system to system. In Loadrunner by defining an initial acceptable response time, we can benchmark the application if it is performing as anticipated.

Measuring transaction response time is important as it gives an idea of how the aplication is performing in terms of time. This performance parameter can be related to the end users at the time of processing request. It helps in understanding how their application performed.

Transaction Response Time is the sum of

Time taken for the request made to the web server Time taken by the web server to process Time taken by the application server to process Time taken by the database server to process Time taken for the procesed request to come back to the client / user through various

routes Time taken for the request or data in the network transmission is also considered in this –

Network latency between the servers and the client

Measuring Transaction Response Time in LoadRuner: It begins when the defined transaction makes a request to the application. From here, till the transaction completes before proceeding with the next subsequent request (in terms of transaction), the time is been measured and will stop when the transaction completes.

How transaction response time is different from Hits Per Seconds: Hits per Seconds is the number of hits made to the web server. These hits can be requests made to the web server for data or graphics. Hits per second measures the number of times the web server is being accessed. So, it does not represent well to users on how well their applications is performing.

Transaction Response Time helps us to find performance bottlenecks in the application. We can further drill down by correlation using other measurements such as the number of virtual users that is accessing the application at the time of measurement. Other system related metrics like CPU Utilization etc. can be used to identify the root cause.

In LoadRuner, after running a performance test, various measurements can be correlated to find trends and bottlenecks. Correlation can be done between the response time, the amount of load that was generated and the payload of all the components of the application.

Users may be unable to understand the meaning of CPU utilization or Memory usage and thus using a common language of time is ideal to convey performance related issues.

Virtual User Generator and Vuser scripts

Vuser scripts are created by Virtual User Generator with the recording of activities between client and server. It records the scripts. These ascripts are used to emulate the steps of real human users. Using Vugen, we can also run the scripts for debugging.

VuGen can be used for recording in windows platforms. But, a recorded Vuser script can also be run on Unix platform.

Developing Vuser Script is a five step process:

Record a Vuser script Vuser Script Enhancement – by adding the control statements and other functions Run time Settings Configuration Running of Vuser Script on Stand Alone machine – Verify that the script runs correctly Integration of Vuser Script – into a LoadRunner scenario or Performance Center or

Tuning module session or Business process monitor profile etc.

When you record a Vuser script, VuGen generates Vuser functions and inserts them into the script. There are two types of Vuser functions:

General Vuser Functions and Protocol-Specific Vuser Functions

Both these functions together form the Mercury VuGen API. It enables Vusers to communicate directly with the server.

There are two types of Vuser scripts:

1. Single protocol Vuser script 2. Multiple protocol Vuser script. Here, we have the option to specify which protocols to

record

Three sections of a Vuser script:

1. vuser_init – It is used when recording a login to a server and it is executed when the Vuser is initialized

2. Actions – It is used when recording a client activity and it is executed when the Vuser is in Running status

3. vuser_end – It is used when recording a logoff procedure and it is executed when the Vuser finishes or is stopped