Introduction

IBM® Rational® Robot provides two mechanisms for recording scripts:

• GUI mode: SQA basic scripts for functional automation
• VU mode: VU scripts used for performance automation

Here, we focus on handling HTTP connections in Rational Robot VU scripts. If you are recording your first Rational Robot VU scripts, the IBM developerWorks article titled "HTTP VU scripts" is essential reading. It will help you understand the recorded scripts and other basic concepts.

Back to top

Rational Robot VU scripts

When you record client/server dialogs, Rational Robot generates a virtual user (VU) script. You can either play back the generated script as-is, or you can edit the script in some fashion to better suit your needs. For example, you could define parameters for the server host name so you could use the same script on multiple hosts. During the VU recording process, Rational Robot monitors the client/server dialog and translates the raw conversation into a series of VU commands to store in the generated script. All of the client requests are translated into a series of VU commands; therefore, a single click on a Web page may generate thousands of lines of VU code. This complicates the process of understanding and subsequently editing the VU script.

In the following example, we take a typical request/response HTTP communication exchange, and then we relate it to the VU script recorded with Rational Robot. Normally, a Web site has a server process listening at TCP port 80 (or another port) for incoming connection requests from clients. For example, if type a request for the Web page http://www.ibm.com/rational.html into your browser, this is the order of events that takes place behind the scenes:

1. The browser parses the entered URL.
2. The browser asks for the DNS for the IP address of the host (www.ibm.com in this example).
3. The DNS replies with the IP address of the host.
4. The browser makes a TCP connection to port 80 on the Web server with the returned IP address.
5. The browser issues a request for the HTTP header, followed by the URL of document. This request uses a get command to solicit a response from the server for the rational.html document.
6. The server responds with an HTTP code in the HTTP header (200, if correct), which is followed by the requested HTML document.
7. The TCP connection is released.
8. The browser parses the HTML and renders the Web page.
9. For any embedded requests in the HTML received — for static content such as GIF, CSS, or JS files, for instance — the browser establishes a new TCP connection to the server and retrieves the files in a similar fashion.

Therefore, each inline image on the Web page means that there must be a separate TCP connection and a repetition of that same process. Now that you understand this fundamental concept, the lengthy VU code generated in the Rational Robot script undoubtedly makes more sense.

Rational Robot VU scripts are made up of repetitive code blocks that represent these steps. These code blocks are separate TCP connections established by the client for executing HTTP get and post requests. Figure 1 shows a snapshot of a recorded Rational Robot VU script:

Back to top

How VU script code affects HTTP connections

Here is how these steps relate to the corresponding VU script code statements generated by Rational Robot:

www_ibm_com = http_request ["Rational~001"] "www.ibm.com:80"
TCP connection to www_ibm_com is active, thus opening a network socket from the client machine to the HTTP server to send http_request "Rational~001".

Set Server_connection = www_ibm_com;
Connection is associated with the response variable set Server_connection.

http_header_recv ["Rational~002"] 200; /* OK */
HTTP header is received from the HTTP server.

http_nrecv ["Rational~003"] 100 %%; /* 20608 bytes */
HTTP response is received.

http_disconnect(www_ibm_com);
Connection is closed.

The recorded VU script will have a number of set server connection statements, which are subsequently closed before the script ends. Automation engineers may choose to edit the scripts to define parameters, to implement custom logic, or to add or remove invalid HTTP requests. However, if you edit the scripts, it is important to pay attention to the http_request and http_disconnect commands. These two commands allocate and free up system resources on the client or Rational Test Agents, so you must match them, in pairs, or your script may result in connection leaks and may block system resources even eventually. That is why it is important that every time you use an http_request statement in the script to open an HTTP connection, you need a corresponding http_disconnect statement that closes the connection.

Back to top

Tradeoffs

Leaving open HTTP connection in VU scripts results in a heavier memory footprints per VU, thus eating up a lot of memory on TestManager and Test Agent machines. Closing every HTTP connection leads to efficient memory use, thus helps scale more VUs on existing resources. Figures 2 and 3, which include observations taken from our workload executions with IBM® Rational® TestManager and IBM® Rational® Test Agent, show the effects. The following are screen shots from Windows Performance Monitor for rtsvui processes on one of the Rational Test Agents.

Note: The figures of 18 and 8 MB may vary on a case-to-case basis, depending on the script and the operations automated.

Rational TestManager and Rational Test Agent also impose upper limits on the number of connections that can be open simultaneously. The default limit is 256 connections. If inefficient script edits cause you to reach this limit at any time during your tests, you may see abnormal VU terminations with the following message in the associated VU data tab: "Failed to connect to "9.182.230.90:80" after 100 attempts: [24.7.5.4] Maximum number of allowed open connections (256) exceeded"

If the total number of open HTTP connections reaches the connection limit on an HTTP server, you are likely to see timed-out connections. That causes your test to terminate prematurely, too, of course.

Back to top

Summary

Now that you understand how IBM Rational Robot handles HTTP connections, you know what precautions to take while editing VU scripts to prevent disruptions and disconnections. Watching for these failure symptoms will also help you identify HTTP connection leaks in your IBM Rational Robot VU scripts.

Resources

Learn

• In the IBM Rational Robot product resource area you'll find technical documentation, how-to articles, education, downloads, product information, and more.
  
  
• Reading HTTP VU scripts (IBM developerWorks, 8 July 2004) is a must-read article if you are recording your first Rational Robot VU scripts. It explains recorded scripts and other basic concepts.
  
  

Get products and technologies

• Visit the Rational products' trial downloads area.
  
  

Discuss

• Participate in the developerWorks blogs to get involved in the developerWorks community.
  
  

About the authors

Comments (Undergoing maintenance)

Back to top

Trademarks  |  My developerWorks terms and conditions

Table of contents

• Introduction
• Rational Robot VU scripts
• How VU script code affects HTTP connections
• Tradeoffs
• Summary
• Resources
• About the authors
• Comments

Local resources

• IBM Innovation Center - Austin, TX
• IBM Innovation Center - Chicago, IL
• IBM Innovation Center - Dallas, TX
• IBM Innovation Center - San Mateo, CA
• IBM Innovation Center - Waltham, MA
• Technical Briefings in North America

My developerWorks community

Dig deeper into Rational on developerWorks

Rate a product. Write a review.

Write a review for Rational products today!

Special offers