 | Level: Intermediate Vaibhav Telang (vaibhav.telang@in.ibm.com), Software Engineer, IBM India Software Labs, Gurgaon, India
Garreth Browne (garreth_browne@ie.ibm.com), System Test Advisory Engineer, IBM Dublin Software Labs, Dublin, Ireland
Morten Kristiansen (Morten_Kristiansen@ie.ibm.com), Software Engineer, IBM Dublin Software Labs, Dublin, Ireland
08 Aug 2006 Learn how IBM Rational Robot VU scripts process HTTP connections. The authors discuss important considerations to keep in mind while editing VU scripts to prevent HTTP connection leaks and avoid heavier memory footprints per virtual user. They will also describe the tradeoffs of leaving open HTTP connections in the VU scripts.
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.
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:
- The browser parses the entered URL.
- The browser asks for the DNS for the IP address of the host (www.ibm.com in this example).
- The DNS replies with the IP address of the host.
- The browser makes a TCP connection to port 80 on the Web server with the returned IP address.
- 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.
- The server responds with an HTTP code in the HTTP header (200, if correct), which is followed by the requested HTML document.
- The TCP connection is released.
- The browser parses the HTML and renders the Web page.
- 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:
Figure 1. Rational Robot VU script
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.
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.
Figure 2. Virtual User script footprint if there are unclosed HTTP connections
Figure 3. Virtual User footprint with all of the HTTP connections properly closed
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.
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
Get products and technologies
Discuss
About the authors | | | Vaibhav Telang is a system software engineer on the System Verification Test Reliability team for Workplace Collaborative Services in the IBM India Software Labs, Pune. His primary expertise is in system tests, and he has developed automation, initiated processes and tool workarounds for reliability test automation and problem determination. He holds a degree in computer science and several certifications, including Sun Certification for Java Developers, Certified Software Test Engineer (CSTE) and Quality Analyst (CSQA) from QAI and Rational TestManagement from IBM Rational. |
| | | Garreth Browne is an advisory engineer for the IBM Workplace Collaborative Services team and technical lead of reliability testing for the System Test team in Dublin, Ireland. He holds degrees in computer engineering and mathematics. |
| | | Morten Kristiansen is a software engineer on the IBM Workplace Collaborative Services team and a reliability testing lead for the System Test team in Dublin, Ireland. |
Rate this page
| |
