LDD Today

Performance perspectives
Using a LoadRunner workload as a model for a Rational workload


by
Yuriy
Veytsman
Level: Intermediate
Works with: Rational, Lotus Team Workplace
Updated: 17-Nov-2003

Over the past several years, Lotus has invested vast amounts of time and effort developing load, scalability, and performance tests for evaluating and tuning our products. The primary tools for these efforts (in addition to internally developed programs) have been Mercury LoadRunner, Segue SilkPerformer, and Server.Load from the NotesBench Consortium. These tools utilize workloads (sometimes referred to as scenarios or test scripts) that simulate user activity and form the core of our evaluation and testing work. As you may have already learned from reading several recent articles and Performance Perspectives columns, IBM recently acquired Rational Software, an industry-leading producer of software testing and analysis tools. Since then, we have embarked on a plan to use Rational tools to create our workloads. At the same time, we still want these workloads to simulate the same types of user activities as the workloads we've already developed using other tools and methods. This helps ensure consistency in our test and analysis results.

This article explains how we used an existing LoadRunner workload for Lotus Team Workplace (QuickPlace) as a blueprint for an IBM Rational Performance Tester workload. In the example we describe, we transform an existing, simple LoadRunner test into an identically performing Rational Robot test script with a minimal amount of change to the workload actually generated during test execution (although given the differences between the two tools, some modifications were unavoidable). The workload we discuss emulates a very limited HTTP-based load on a Lotus Team Workplace server. (You can download the complete code for the workload from the Sandbox.)

Our goal is to share our experiences migrating a simple LoadRunner workload to Rational. However, we do not cover all possible issues that may result from working with longer and more complex workloads. This would require far more explanation than a single article can provide. However, we feel our observations and advice should help others who may be interested in adopting Rational tools both to migrate existing HTTP-based workloads and to build workloads from scratch.

This article assumes that you're familiar with LoadRunner and workloads in general. And although some knowledge of Rational tools may be helpful, we hope readers new to Rational can still learn from this article. Visit the Rational Developer Domain for articles and related information about Rational products.

Our original Lotus Team Workplace user workload
To build our Rational workload, we started with a Lotus Team Workplace (LTW) workload that we created previously in LoadRunner. We used this workload as a "pattern." Following this pattern helped save time because it showed us how all the components of the workload fit together. Also, this allowed us to examine both the Rational and LoadRunner scripts in parallel and to determine how well their variables correlated.

The LoadRunner workload we migrated to Rational performs the following LTW user actions:
There are two primary ways we can re-create this workload with Rational Robot:
Because our original LoadRunner script is relatively simple, we decided to use the Rational Robot record function to re-create it. To do this, we followed the same basic procedure we used when creating scripts with LoadRunner:
Using the Rational Robot record feature
As we mentioned in a previous Performance Perspectives column, IBM Rational Performance Tester includes several integrated components, each with a specific purpose in the performance testing workflow:
To duplicate our LoadRunner script, we used Rational Robot to record LTW user activity, using timers to measure response time for transactions. We also added comments to distinguish each transaction. Before recording the activity, we set the following record options in Rational Robot:
Rational Robot record feature options

The result was a script that resembles a LoadRunner recording log, as shown in the following:

We then needed to modify the script to generalize the specific activity we recorded, to allow it to be used to build a multi-user workload, and to run on different servers with different users and so on. To do this, we "parameterized" the script, changing hard-wired values to variables. This is a fairly simple procedure in Rational Robot.

Building the datapool
We started by creating the following datapool (note that Rational Robot datapools are equivalent to LoadRunner parameters). We created this datapool automatically by using Rational Robot's Datapool service:

DATAPOOL_CONFIG "qp2” DP_SHARED DP_WRAP
{ }

In the preceding code:
As you can see, we used the INCLUDE statement to enable just three parameters to be used in our script: servername (the name of the user's server), quickplace (the name of the Web site), and user (the name of the simulated user). Note that the Datapool service worked fine for building our simple script. However, more complicated scripts may need to be done manually. See the Rational documentation for more information.

Performing open and fetch on the datapool
To use variables contained in the datapool, you must perform open and fetch operations on the datapool as follows:

DP1 = datapool_open ("qp2"); //Open Datapool
datapool_fetch (DP1); //Fetch Datapool

This allows you to access the datapool variables via the function datapool_value (“datapool name”, “variable name”):

usr = datapool_value (DP1, "user");

Putting variables in the URLs
As you can see, all variables in the datapool are strings. To build URLs from these strings, use the following format:

"Host:” + servername + "\r\n”

where servername is the variable from the datapool.

Procedures
We recommend that you put sections of code that you use often into separate procedures and include these procedures either in a separate header file or at the top of the main script file. An example of a simple procedure follows:

/* Traverse one page with 12 quickplaces
*/
proc dopages(servername, npages)
And you can call your procedure from the main script like this:

dopages (sname, 10);

For detailed information about using procedures, consult the Rational documentation.

Handling cookies
In our test case, SSO (single sign-on) is enabled and user authentication kept by LtpaToken, a cookie (created on the fly by the server) that changes for every user and every session. Our original Rational Robot recording produced a hard-coded token that only works for the server on which it was recorded. We, therefore, need a way to change this token, so it can run on other servers. By examining our recording, we see that the token has been set in the header to the value for Set-Cookie. To pick up the token value, we used the function http_header_info ("Set-Cookie"). The http_header_info function scans the headers received by http_header_recv to locate lines beginning with the requested attribute (“Set-Cookie") and returns a string containing the value of this attribute:

LtpaToken =http_header_info ("Set-Cookie");

Using this routine:

helps us pick up the whole token and put its value into the variable result (or exit if no token value exists). Thus, together these two Rational Robot functions work similar to the LoadRunner function web_reg_save_param ().

Print output for debugging purposes
It is always a good idea to print variables to a file to see how they change when you play your script:

fprintf (fd, "servername: %s\n", sname);

We have found routines, such as this one, reliable and simple to implement.

Results
After we finished creating the script, we were eager to run it against the same server we used to run the LoadRunner workload. We measured response time for each script during one hour of simulated activity and found the results of the Rational Robot workload comparable to the LoadRunner workload:

Rational Robot workload vs LoadRunner workload

Conclusion
This article describes how to create a Rational script that performs the same actions as a Mercury LoadRunner script. Using Rational Robot, we were able to:
Converting scripts to Rational allows us to take advantage of the integrated toolset and methodology offered by Rational. These tools support the full range of product development from concept to coding to product release. In addition, Rational tools integrate with current and future IBM products—a compelling reason for IBM customers to consider adopting Rational tools at their sites.

Bear in mind that we're still new at this. We expect to learn more as we migrate other existing workloads into our expanding Rational environment. As we do, we will likely encounter more complex issues not discussed in this article. However, our simple example demonstrates that migration is in fact possible and doesn't necessarily require a great deal of time and effort. This should be good news to users who have experience with HTTP-based workloads and similar tools and are now considering adopting Rational tools to meet their load and scalability analysis needs. Give it a try and see for yourself!


ABOUT THE AUTHOR
Yuriy Veytsman has been a Staff Software Engineer with IBM/Lotus since the late 1990's, working on projects involving Domino Web Access (iNotes), Discovery Server, Lotus Team Workplace (QuickPlace), and Lotus Instant Messaging (Sametime) testing, and various other responsibilities. Previously, Yuriy was employed developing a variety of software and hardware applications for numerous companies throughout Europe.