My Load Test

The Virtual Table Server is great for most situations where your virtual users need a common data pool, but the limitations of the API mean that it is a bad fit in some cases.

Say you need to find a row in the data table with a specific value. On a real database you could just do a simple SELECT statement. With VTS, you would have to write code to iterate through every row in the table and check the column value each time.

So sometimes you need to use a real database. Interfacing with a real database is not much harder than interfacing with VTS (as the attached script demonstrates). You will spend more time setting up the database than writing code.

Interfacing with a real database will also allow you talk to the database your application uses (only do read-only operations, and be careful of any additional overhead you might introduce during your load test).

This example users the Java vuser type, and interfaces with a MySQL database. The beauty of JDBC is that to port this code to another database just requires changing the line of code that specifies the database driver (assuming that you have not used database-specific SQL code).

On with the example…

Setting up the database

1. Download and install MySQL.
2. Create a database
   mysql> CREATE DATABASE loadtest;
mysql> SHOW DATABASES;
mysql> USE loadtest;
3. Create a table
   mysql> CREATE TABLE message (time_sent BIGINT UNSIGNED, identifier VARCHAR(127));
mysql> SHOW TABLES;
mysql> DESCRIBE message;

4. Load data into the table
   mysql> INSERT INTO message VALUES ('1178858071111','asdf1234');
mysql> INSERT INTO message VALUES ('1178858071112','asdf1235');
mysql> INSERT INTO message VALUES ('1178858071113','asdf1236');
mysql> INSERT INTO message VALUES ('1178858071114','asdf1237');
mysql> INSERT INTO message VALUES ('1178858071115','asdf1238');
mysql> SELECT * FROM message;
5. Create a user account with access to the database.
mysql> GRANT ALL PRIVILEGES ON loadtest.* TO 'loadrunner'@'%' IDENTIFIED BY 'loadrunner' WITH GRANT OPTION;
Note username/password is loadrunner/loadrunner.
mysql> SELECT * FROM mysql.user where User = 'loadrunner';

Verifying external connectivity to the database

1. Download an SQL query tool to verify that you can successfully connect to the database.
   I recommend that you check out SQLeonardo.
2. Download the JDBC driver for MySQL.
   MySQL now produce their own JDBC driver (Connector/J)
3. Configure the SQL query tool.
   nickyb (the creator of SQLeonardo says)…

   Suppose you have downloaded and unzipped sqleonardo into c:\sqleonardo and the mysql jdbc driver into c:\sqleonardo\mysql

   Run SQLeonardo and into the “metadata explorer” do:
   - choose the menu “actions>new driver…”
   - check “add library (browse filesystem)” and click “next >”
   - select the jar file into c:\sqleonardo\mysql and click “next >”
   - type into the textfield named “name:” => MySQL
   - select into the combobox named “driver:” => com.mysql.jdbc.Driver
   - into “example:” => jdbc:mysql://[host][:port]/[database]
   - click ok.
   now you have registered the driver!

   Select the item “MySQL” appeared into the tree and:
   - choose the menu “actions>new datasource…”
   - replace jdbc:mysql://[host][:port]/[database] => jdbc:mysql://localhost:3306/
   - put username and password and click ok.
   now you have added your database profile.

   Select the item under “MySQL”…you need now to test the connection!

   So our database connection string would be jdbc:mysql://www.myloadtest.com:3306/loadtest (assuming the database is installed on the default port).

4. Test the connection.
   Try running SELECT * FROM message; in your SQL query tool.

Writing the code

1. Java.sql javadocs are here. There are numerous tutorials on the web, and you have my sample code (text, zipped). What more do you need?

Correlation is one of the fundamental LoadRunner scripting skills; and LoadRunner novices are usually not very good at it (which is expected), but people who think they are LoadRunner experts are sometimes not very good at it either.

Mercury has done just about everything it can to remove the need for complicated correlation (correlation rules, the “scan script for correlations” option in VuGen, HTML mode recording, the Click and Script vuser type), but there will always be web applications that will require you to perform manual correlation when scripting.

Mercury’s training material kind of glosses over correlation, and makes it look overly easy - the correlation exercise from the training material never gives any of my students any problems; but if the training material were to include difficult exercises, it would be necessary to spend another day, and more people would be unable to complete the exercises.

I usually tell my students that they will encounter some much more difficult to correlate applications than the Mercury Tours website, and they will need to spend some time improving their manual correlation skills using WDiff .

This exercise should really test your correlation skills. Every problem (or something very similar) has been seen “in the wild” while I have been creating scripts for LoadRunner. The first exercise is the same as the exercise from Mercury’s VuGen 8.1 Scripting for the Web training material.

Correlation exercise coming soon…

Until the, have a go at the previous scripting exercises:

• Scripting Exercise: Credit Card Challenge
• Scripting Exercise: A basic AJAX application
• Scripting Exercise: Unique Usernames

This is a quick walkthrough of a LoadRunner script I created to load test a “web” service that communicates with SOAP messages sent over JMS.

Note that this script supports the queuing/point-to-point model of JMS (rather than the publish and subscribe model), works with JMS version 1.1 rather than 1.02b (as it uses the BytesMessage.getBodyLength() method among others), and has been tested with Java 1.5 using the Tibco implementation of JMS.

The LoadRunner script can be downloaded here, the source code is available here, and a mirror of the JMS 1.1 specification can be downloaded here. People using Tibco’s JMS implementation can download their Javadocs here (10MB). Feedback is appreciated.

From looking at the script, you may wonder why I chose to write my own script using the Java vuser type instead of using the Web Services vuser (version 8.1, Feature Pack 4 supports web services using JMS as well as HTTP), but that is a story for some other time.

Anyway…for the tiny number of people that I haven’t lost already, here’s how it all works…

At a high level, we are trying to put a SOAP message on a queue (MyLoadTest.Warehouse.Request), receive the corresponding response from a different queue (MyLoadTest.Warehouse.Response), and check that the response message matches our expected message. Download my source code and follow along.

On with the detail…

The javax.jms.* classes provide interfaces only, other vendors have provided implementations of these interfaces (I am using Tibco’s implementation - found in com.tibco.tibjms.*). This should mean that any JMS code you write will be portable between implementations; whether this is true or not is something I haven’t tested.

Initially we perform a JNDI lookup to find a ConnectionFactory and get the details for the queues we will be using.

We then create a Connection and a Session, and then create the MessageProducer (using the request queue details) that we will be using to send our message to the request queue.

We create either BytesMessage or a TextMessage (MapMessage, ObjectMessage and StreamMessage have not been implemented in the script), and set the JMS header properties. The important JMS headers are the JMSDestination (the request queue), and the JMSReplyTo (the response queue). We can also set Message properties, which are simple name/value pairs. We then set the Message body, using a string constant containing the SOAP XML message.

We only want to measure system response times, so we only put our LoadRunner transaction timing points around the code that sends and receives the message.

Sending the message is as simple as calling myMessageProducer.send(myMessage).

In the following extract from the Tibco EMS logs, you can see the JMS headers, the Message properties and the Message body (shown here with a size only). The JMS headers show the request and response queues along with a unique msgID.

2007-02-26 13:20:07 [MSG:73422]
received from user=’anonymous’:
connID=1669
prodID=16906
msgID=’ID:SVP-EMS-SERVER.391E45DA4ADA6C8:3083′
Time=1172456256000
mode=PERSISTENT
queue=’MyLoadTest.Warehouse.Request’
msg=BytesMessage=
{
  Header=
  {
    JMSDestination={QUEUE:’MyLoadTest.Warehouse.Request’}
    JMSReplyTo={QUEUE:’MyLoadTest.Warehouse.Response’}
    JMSDeliveryMode={PERSISTENT}
    JMSPriority={4}
    JMSMessageID={ID:SVP-EMS-SERVER.391E45DA4ADA6C8:3083}
    JMSType={BytesMessage} JMSTimestamp={1172456256000}
  }
  Properties=
  {
    ”SOAPJMS_requestIRI”={string:”}
    ”SOAPJMS_targetService”={string:”}
    ”SOAPJMS_soapAction”={string:”}
    ”SOAPJMS_isFault”={string:’false’}
    ”SOAPJMS_contentType”={string:”}
    ”SOAPJMS_soapMEP”={string:’http://www.w3.org/2003/05/soap/mep/request-response/’}
    ”SOAPJMS_bindingVersion”={string:”}
  }
  Body=
  {
    byte[]:1126 bytes
  }
}

To receive a Message, we must create a MessageConsumer (using the response queue). Rather than simply receiving the messages from the queue in the order they arrived (FIFO - which would mean that we could be receiving the wrong response message when we are running load against the system), we can use a message selector to make sure that we receive the message that we want from the queue.

In the log above, we saw that each JMS message has a unique JMSMessageID. When a response is sent by the server, the response message has a JMSCorrelationID that matches the JMSMessageID of the message it is replying to. A message selector is defined in the same way as the WHERE clause of an SQL statement, so our selector would be
"JMSCorrelationID = '" + myBytesMessage.getMessageID() + "'".
Note that the unique message ID is only set when the message is sent so, if you are using a selector, you must create your MessageConsumer *after* you have called myMessageProducer.send(myMessage). A selector can use any of the JMS headers and Message properties, but cannot use the Message body.

Using the MessageConsumer, receiving the correct message from the queue is done by simply calling myMessageConsumer.receive(timeout). The script will wait to receive the message until it reaches the timeout value. If no message is received before the timeout, the response message will be null. Remember to close the MessageConsumer, or you will leak and end your test with thousands of open receivers.

Here is the Tibco EMS log entry for the response message. You can see that the message has a different JMSMessageID, and has a JMSCorrelationID with the message ID of the request it is replying to.

2007-02-26 13:20:09 [MSG:73425]
received from user=’anonymous’:
connID=1714
prodID=19956
msgID=’ID:SVP-EMS-SERVER.391E45DA4ADA6F5:7835′
Time=1172456409014
mode=PERSISTENT
queue=’MyLoadTest.Warehouse.Response’
msg=BytesMessage=
{
  Header=
  {
    JMSDestination={QUEUE:’MyLoadTest.Warehouse.Response’}
    JMSDeliveryMode={PERSISTENT}
    JMSPriority={4}
    JMSMessageID={ID:SVP-EMS-SERVER.391E45DA4ADA6F5:7835}
    JMSCorrelationID={ID:SVP-EMS-SERVER.391E45DA4ADA6C8:3083}
    JMSTimestamp={1172456409014}
  }
  Properties=
  {
    ”SOAPJMS_requestIRI”={string:”}
    ”SOAPJMS_contentType”={string:’text/xml’}
    ”SOAPJMS_soapMEP”={string:’http://www.w3.org/2003/05/soap/mep/request-response/’}
    ”SOAPJMS_bindingVersion”={string:”}
  }
  Body=
  {
    byte[]:681 bytes
  }
}

Extracting contents of the Message body from the JMS Message is done by calling myMessage.getText() if it is a TextMessage (if it is a BytesMessage, it is a bit trickier - see the attached script).

And finally comparing the received SOAP message to the expected message is just done using String.equals().

Remember to close the Session and Connection at the end of the script.

The exercise of modifying the script to send many different messages to different queues (which would mean you only have to maintain one script instead of one script per SOAP operation) is left as an exercise for the reader…

A LoadRunner feature that has made my life a lot easier has been ContentCheck rules, which are available in the script runtime settings. If you are using a web-based vuser type, you can configure your LoadRunner script to search through all returned pages for strings that match known error messages.

Using web_reg_find functions is fine, but when you get an error LoadRunner reports it as “failed to find text” instead of something more descriptive.

I will always create rules for any error messages I find during scripting and, if I receive an error while running a scenario, I will add the error message from the snapshot in the scenario results directory (the snapshot on error feature is very useful).

All this is pretty obvious if you have taken the time to explore LoadRunner’s features or you have attended a Mercury training session, but I recommend taking things a step further.

• Ask your developers for a list of all the error messages that the application can throw. This should be easy for them to provide if the application is well designed and stores all the message in some kind of message repository instead of sprinkling them throughout the source code.
• Include error message for functional errors that you are likely to encounter. Creating a rule for “incorrect username or password” may save someone 20 minutes of investigation when they first run the script after the database has been refreshed.

If you prefer to have error message you are checking for in the script (where you can add comments to them) instead of the runtime settings, you can use the web_global_verification function instead. The only difference between the two is the error message that LoadRunner will include in its log:

Action.c(737): Error -26368: “Text=A runtime error occurred” found for web_global_verification (”ARuntimeErrorOccurred”) (count=1), Snapshot Info [MSH 0 21]

…compared to:

Action.c(737): Error -26372: ContentCheck Rule “ARuntimeErrorOccurred” in Application “Webshop” triggered. Text “A runtime error occurred” matched (count=1), Snapshot Info [MSH 0 21]

And finally, ContentCheck rules can be easily exported and shared between scripts, which can be a nice time-saver.

As part of the LoadRunner 8.1 Hands-On Lab training, there is an exercise to enhance a VuGen script that books a flight using the Mercury Tours application.

Company “A” wants the script to generate 10 digit credit card numbers instead of supplying them from an external source on every iteration and for an unlimited number of iterations.

How do you make the script generate credit card numbers for every iteration?

As the Mercury Tours application does not check if the credit card numbers conform to a valid format, the answer to this question is just to replace the file-based credit card parameter with a random parameter using a number format of %010lu.

The purpose of Mercury’s training is to cover as much of the basic concepts as possible in a short space of time, so they can’t make the exercises too hard; but I don’t like to leave people with the incorrect idea that just because they’ve finished some training they are totally prepared for the level of difficulty they will encounter in the real world.

I have created an exercise where you will need to submit different credit card numbers, but I have made it more difficult as they must be valid credit card numbers.

Start the Credit Card Validation Exercise here.

Some quick notes:

• The exercise is quite simple. If you work intelligently (and do some research), it should not take long.
• Make sure that you really do generate the cards at runtime. Finding 60 different card numbers on the web, trying card numbers at random until you find ones that work, and generating card numbers outside of LoadRunner all miss the point of the scripting exercise.
• Do not run load against my server. Don’t run more than 1 virtual user at a time and be kind with your thinktime and pacing settings.
• Please report functional defects to me via email: stuart at myloadtest dot com
• Once some people have emailed me their solution scripts, I will post some comments about my preferred solution.

Here are some credit card numbers to get you started:

• 30100000000002 (Diners)
• 30100000000010 (Diners)
• 4000000000000002 (VISA)
• 4000000000000010 (VISA)
• 5400000000000005 (MasterCard)
• 5400000000000013 (MasterCard)
• 340000000000009 (American Express)
• 340000000000017 (American Express)

Good luck!

Imagine that you have to create a script for the “Create New User Account” business process. There are several constraints that will make your job difficult…

The username field has the following properties:

• valid characters are a-z, A-Z, 0-9
• usernames are not case sensitive. “Stuart” is the same as “stuart”.
• usernames must start with a letter, not a number.
• usernames may be a maximum of 8 characters long.
• username must not be a duplicate

Some other information about your testing:

• It is unclear when the database in the test environment will be refreshed, but it should happen at least yearly. It will definitely not be refreshed for every test run, and it will not be possible to delete any of the user accounts that you have created.
• The business process takes a minimum of 1 minute to run from start to finish.
• There will be a maximum of 99 virtual users executing the business process in the scenario.
• It is possible that virtual users will execute the business process at exactly the same time.

How do you create usernames that meet all of the above criteria without creating any duplicates? Create a script or provide a descriptive solution.

See the comments section for my solution…

When running a training or mentoring session, people often ask what runtime settings they should use; as if there is a magical list of settings that will always be correct for any testing situation. Obviously you select runtime settings that are appropriate for what you are trying to achieve with your test, but the funny thing is that there are actually a small list of settings that are usually appropriate for most situations. Read on…

Whenever I am using a vuser type that allows multiple actions in a single script, I will create a separate action for each business process and put appropriate percentage weightings on each action. It is very unusual to have to do anything more complicated than this. I don’t usually use the “sequential” option or create blocks unless I need to have fractional percentage weightings for a business process - percentages must be integer values, so to run a business process 0.1% of the time you could create a block that runs 1% of the time, and put an action in the block that runs 10% of the time.

It’s also rare to set a script in a scenario to run for a specified number of iterations (mostly done by time or set to run indefinitely). Generally “number of iterations” is only used when running the script in VuGen.

• “As soon as the previous iteration ends” is used when running in VuGen or when loading/verifying data. Do not use this for load testing
• I have never seen the point of the “After the previous iteration ends” option. Why would you want to run an unknown number of transactions per hour against the system?
• Don’t use the “At fixed intervals”. If something causes your users to become “in step”, they will tend to stay that way and continue to all hit the server at the same time.
• “At random intervals” is definitely the way to go. Obviously for your users to create a certain number of orders per hour the iteration time must average to 3600/num iterations in an hour. Do not make the lower boundary value any bigger than the maximum time it takes to complete the business process, or you will end up creating less transactions per hour than you intend to.

• Logging creates additional overhead on your load generators, and can create huge log files.
• I log absolutely everything when debugging in VuGen.
• When running the script as part of a scenario, I leave extended logging on but change the logging to “Send messages only when an error occurs”. This gives a little more information than turning logging off entirely, and won’t create any additional overhead while everything is running smoothly (and if the system is not running smoothly you are going to need to stop the test and investigate anyway).

• Just like the pacing setting, I think that it is a good idea to put some randomness in your think times.
• I use a random percentage of 50-150% of recorded think times.
• Use “Ignore think time” if you are debugging in VuGen or if you are loading/verifying data.

• This option is ignored by most people. It is used to create a parameter with a given value without having to edit the script (as runtime settings can be overridden in the Controller).
• In the screenshot I have created a parameter of ServerName with the address of the test envioronment. If you were testing in more than one test environment at a time, this would make save some time.

• Continue on error is generally only going to be used if you have written code to do something when you encounter an error. Usually the default behaviour of ending the current iteration and then starting the next one is sufficient). I don’t advise anyone to try to write a script that handles errors in the same way as a real user because it will create a lot of additional work for very little benefit, but doing something simple like writing some useful information to the logs and then calling lr_exit(LR_EXIT_ACTION_AND_CONTINUE , LR_FAIL) can be useful.
• “Fail open transactions on lr_error_message” should always be ticked. If you are raising an error, you should fail the transaction step that you are performing.
• “Generate snapshot on error” is useful. If it is a web script, any error messages should be added to your content check rules.
• Run your virtual user as a thread unless you have code that is not threadsafe or there is some other reason to run your virtual users as a process. The overall memory footprint on your load generators will be higher if you run as a process.
• I never use the “Define each action as a transaction” option. If I want a transaction in my script I will add it myself with lr_start_transaction.
• I never use “Define each step as a transaction” either. If it is a web script, I can use the transaction breakdown graph to get this information, otherwise I will add the transactions myself.

• Not all vuser types have this option available.
• Most of the time my virtual users will use the maximum bandwidth.
• If I want to emulate users with bandwidth constraints, I will do this in a separate scenario.
• Google calculator is handy to calculate bitrates if your bitrate is not available from the drop-down list e.g./ “256 Kbps in bps”

All of the following settings only apply to web-based scripts. Each vuser type will have its own runtime setting options. It is important to know what they mean and how they will influence your test results before running any tests that you plan to report on.

• Some people get confused by the User-Agent (browser to be emulated) setting. If 90% of your users use Internet Explorer 6.0 and the rest use Firefox 1.5, you don’t have to change the runtime settings for your users to match this. All it changes is the string that is sent in the “User-Agent” field of your HTTP requests. This is completely pointless unless your application has been written to serve different content to different browsers based on the User-Agent field.
• TODO

• Generally people won’t be using your web applications through your proxy server, so it shouldn’t be part of your test either.
• If you start getting errors that are due a proxy server rather than the system under test, it will just confuse the people who have to fix the problem.
• A proxy server will also make IP-based load balancing ineffective.
• If it’s an intranet application and everyone will be using the application through the company’s proxy, then the proxy server should be explicity declared to be in scope for your load test. You should make sure that you have an identical proxy server for your test environment, or that you have permission to be generating load on a piece of Production infrastructure.

• TODO

• These settings are default values specified by Mercury, rather than being inherited from the web browser that is installed on your workstation. Generally you will not need to change them, but be aware that they are here.

• Download filters are a quick way of preventing your scripts from downloading content from certain URLs or hosts/domains.
• I generally use this feature when the web application in the test environment contains third-party images used for tracking website usage (e.g. images from Webtrends or Red Sheriff etc).
• I think it is better to specify which hosts your script is allowed connect to, rather than which hosts your script can’t connect to (because it’s easy to miss one accidentally, or the application may change and refer to a new third-party domain).
• Use web_add_auto_filter if you want to specify this in your script rather than your runtime settings.

• I have talked about Content Check rules before; I think that if you aren’t using them already, then you are not getting the most out of the LoadRunner feature-set.

As of LoadRunner 8.1, Feature Pack 3, the following Vuser types are available (note that descriptions are provided by Mercury).

Application Deployment Solutions

• Citrix_ICA
  Represent the Citrix ICA protocol communication between the Citrix client and server as GUI events.

Client/Server

• DB2 CLI
  The IBM Call Level SQL Interface to the DB2 family of databases.
• Domain Name Resolution (DNS)
  A system which translates domain names into internet addresses.
• Informix
  IBM’s Informix Database servers.
• MS SQL Server
  Microsoft’s SQL Server using the Dblib interface.
• ODBC
  Open Database Connectivity - a protocol providing a common interface for accessing databases.
• Oracle (2-Tier)
  Oracle database using a standard client/server architecture.
• Sybase CTlib
  A client/server architecture database called via the Ctlib interface.
• Sybase DBlib
  A client/server architecture database called via the Dblib interface.
• Windows Sockets
  The standard network programming interface for the Windows platform.

Custom

• C Vuser
  A generic virtual user which uses the standard C library.
• Java Vuser
  Java programming language with protocol level support.
• Javascript Vuser
  A scripting language used to develop Internet applications.
• VB Script Vuser
  Visual Basic Scripting Edition language - used for programming documents displayed in Web browsers.
• VB Vuser
  Vuser scripts written in Visual Basic language.
• VBNet Vuser
  Vuser scripts written in Visual Basic language.

Distributed Components

• COM/DCOM
  Microsoft’s Distributed Component Object Model (COM/DCOM) for distributed computing.
• Corba-Java
  Java scripts which use CORBA architecture giving applications the ability to work together over networks.
• Rmi-Java
  Remote Method Invocation - a technology providing remote communications between programs written in the Java programming language.

E-Business

• Action Message Format (AMF)
  A Macromedia proprietry protocol that allows Flash Remoting binary data to be exchanged between a Flash application and an application server over HTTP.
• File Transfer Protocol (FTP)
  File Transfer Protocol - a system which transfers files from one location to another over a network.
• Listing Directory Service (LDAP)
  Record directory based authentication, listings, searches and related transactions.
• Microsoft.NET
  Supports Microsoft ADO.NET.
• Palm
  Palm Handheld computers.
• Web (Click and Script)
  Emulation of the communication between a web browser and the web server at user-action level.
• Web (HTTP/HTML)
  Emulation of communication between a browser and Web server.
• Web Services
  Web Services - a software interface defined and described using XML.
• Web/Winsocket Dual Protocol
  A dual protocol incorporating the Web and Winsocket Protocols.

ERP/CRM

• Oracle NCA
  Oracle 3-tier architecture database consisting of Java client, Web server and database.
• Oracle Web Applications 11i
  In addition to Web HTTP/HTML features, supports the user action level API and JavaScript, with a high level of support for Oracle Web Applications 11i environment.
• PeopleSoft Enterprise
  In addition to Web HTTP/HTML features, supports the user action level API and JavaScript, with a high level of support for PeopleSoft environment specifics..
• PeopleSoft-Tuxedo
  An Enterprise Resource Planning system based on the Tuxedo Transaction Processing Monitor, including automatic correlation.
• SAP - Web
  Similar to Web HTTP/HTML, but equipped to work in conjunction with SAP.
• SAPGUI
  SAPGUI protocol for SAP Front End, versions 6.20 and higher.
• SAPGUI/SAP-Web Dual Protocol
  SAPGUI and SAP-Web dual protocol for SAP Front End, versions 6.20 and higher.
• Siebel - DB2 CLI
  A Customer Relationship Management Application based on a DB2 database.
• Siebel - MSSQL
  A Customer Relationship Management Application based on the ODBC database API.
• Siebel - Oracle
  A Customer Relationship Management Application based on an Oracle database.
• Siebel - Web
  Similar to Web HTTP/HTML, but equipped to work in conjunction with Siebel, a Customer Relationship Management Application.

Enterprise Java Beans

• Enterprise Java Beans (EJB)
  Enterprise Java Beans - an architecture for the development and deployment of Java-server components.
• Rmi-Java
  Remote Method Invocation - a technology providing remote communications between programs written in the Java programming language.

Legacy

• Terminal Emulation (RTE)
  Emulation of users who submit input to, and receive output from, character-based applications.

Mailing Services

• Internet Messaging (IMAP)
  Internet Message Application - a protocol which enables clients to read email from a mail server.
• MS Exchange (MAPI)
  Messaging Application Programming Interface designed to allow applications to send and receive email messages.
• Post Office Protocol (POP3)
  A protocol designed to allow single computers to retrieve email from a mail server.
• Simple Mail Protocol (SMTP)
  Simple Mail Transfer Protocol - a system for distributing mail to a particular machine.

Middleware

• Jacada
  A gateway server providing clients with a Java user interface to mainframe applications.
• Tuxedo 6
  Tuxedo 6.x Transaction Processing Monitors.
• Tuxedo 7
  Tuxedo 7.x Transaction Processing Monitors.

Streaming

• Media Player (MMS)
  Streaming data from a media server using Microsoft’s MMS protocol.
• Real
  A protocol used to transfer streaming data from a media server.

Wireless

• i-mode
  NTT DoCoMo’s technology for accessing the Internet on a mobile phone system.
• Multimedia Messaging Service (MMS)
  Multimedia Messaging Service - used for sending MMS messages between mobile devices.
• VoiceXML
  A standard for voice-based communication between applications.
• WAP
  Wireless Application Protocol - used for Web-based, wireless communication between mobile devices and content providers.

The Virtual Table Server (VTS) is an in-memory database that can be used to share data between virtual users. I have found this useful when I need my VUsers to pass data to each other; it’s certainly a much neater solution than writing to a file and having each VUser check the value in the file on every iteration.

Here is what the documentation has to say about it…

VTS Virtual Table Server (version 2.10)

Virtual Table Server (VTS) first edition, introduced the capability for LoadRunner virtual users, WinRunner and XRunner, to communicate in real time. Data extraction and communication was simplified but limited to column/queue level operations. The new Virtual Table Server II provides a higher degree of data manipulation and 5-10 times better performance. From row level queries, retrievals, updates, insertions, unqueue entries, to database access, VTS II provides the functionality and ease for enhanced inter-process, inter-virtual user communication

One of the limitations of LoadRunner is that a parameter file cannot be shared between different scripts, or between instances of the same script running on different load generators. VTS is an easy way to maintain a single data pool. This is less of a problem if you are using Performance Center, as it is smart enough to allow the same script to run on multiple generators and still maintain the “Select next row: unique” property.

Another limitation that the VTS solves is the ability to maintain information about which data values have been used *between* runs. If you have a script that consumes data (maybe it deletes records), data values can only be used once. This means that every time you run the script, you have to update the data file. Using VTS, you can mark the data as “dirty”, so the next time the script is run, it will use a different value.

Virtual Table Server (version 2) can be downloaded from the Mercury Support website. Note that even though the software is provided by Mercury, it is not officially supported.

Installation is simple, and the server can be configured to run on any port. The API and examples provided with the software work with C-based scripts. A Java API is also provided. JavaScript and VBScript vuser types are not supported.

The API is simple, but unfortunately does not allow you to write SQL queries; instead you must use the functions provided, like lrvtc_retrieve_row() and lrvtc_query_row(). Finally, the VTS can import from and export to a regular database (anything with an ODBC driver), or a text file.

This is a useful tool for anyone who uses LoadRunner to be aware of.

A common question on the LoadRunner support forums is “I’ve got an application that uses this new thing called AJAX. Will LoadRunner work with my application?” …and the answer is “yes…but…”.

The “but” is a big one . An “AJAX” application can mean anything from a simple webpage that updates some fields with information from the server (without reloading the whole page), to a horribly complicated rich GUI interface created with JavaScript.

Of course LoadRunner is going to be able to handle anything that is sent over HTTP, but scripting might not be the usual simple Record-Correlate-Playback, and the chances of the new Click and Script vuser type working are much lower than with a standard web application.

As a quick introduction to AJAX I have prepared an exercise using the simplest AJAX application that I could find.

Google Suggest is just like Google’s regular search interface, except that every time you type a letter in the search field, a request is made to the server that returns search suggestions.

The exercises are as follows:

1. Become familiar with the application - both at an end-user level, and at the HTTP level. Record the script in HTML and URL mode, then try the Click and Script vuser type (at the time of writing, this vuser type will not correctly record the application).
2. Create a script for this application. It should accept a parameter file that contains a valid search term on each line. Create the following transactions load_search_page, enter_character (called every time a character is entered in the search field), and final_search (where the Google Search button is pressed).
3. Imagine that you’ve noticed an odd step-like pattern in the Percentile graph in LoadRunner analysis. You hypothesise that response times differ depending on how many characters have been entered in the search field. Modify the enter_character transaction name to include the length of the search term every time it is called.

Treat this with the same level of care that you would give a script that you were creating for a paying client.

I have added some notes and a solution script to the comments section of this post. If you are going to attempt this exercise, please do so before reading the comments.