InformationWeek.com

Welcome Guest. | Log In| Register | Membership Benefits

January 17, 2000

Web-Site Testing Tools:
Is Your Web Site Scalable Enough?
continued...page 2 of 4

Related links:

sidebar: Be Realistic When Testing Web Sites

New Software Tools Help Monitor And Test Web Apps

And from our sister publications:

EETimes Credence rolls built-off self-test

Send Us Your Feedback

After playing back for some predetermined amount of time, number of iterations, or until some rule is met (such as "stop when the response time is greater than 5 seconds"), the playback ends, and a report is generated based on the performance data collected.

Each product consists of three applications: a script recorder for creating workload scripts, a controller for controlling the stress-testing of the Web application, and a reporting tool to create reports based on the performance data. Each product also includes distributed workload generation software that lets the controller run workload scripts off any attached Windows NT machines.

Although it would seem that playing back client mouse clicks and keystrokes to the Web application would be straightforward, it's actually fairly complex, and there are two basic ways of playing back user scripts.

The simplest way is to send and receive the HTTP traffic generated by the user's mouse clicks and keyboard input. This method is sometimes referred to as an HTTP recorder. The problem with this approach is that there may be client-side interactions that affect the HTTP traffic. Ignoring these interactions can cause errors and confusion, rendering the results invalid. For example, unique session IDs generated by some application servers may be appended to URLs that are sent and received within the HTTP requests. These session IDs are often stored in client-side cookies. Other client-side interactions that can affect HTTP traffic include JavaScript scripts that may be sent back to the client for execution, Secure Sockets Layer sessions that may be initiated and torn down, URL redirection, digital certificate authentication, downloading and execution of ActiveX controls or Java applets, and username/ password input with various possible authentication schemes such as NTLM (NT LAN Manager authentication). All three products offer an HTTP recorder mode for playback.

A higher level of abstraction, where the actual user mouse clicks and keystrokes are stored and replayed against Web-page objects (form input, graphics, links, etc.), works much better than merely sending and receiving HTTP, but is also more complex to implement. Both e-Load and Astra LoadTest offer a mode with this type of abstraction.

Whether you choose to use a thinner client approach, which a basic HTTP recorder provides, or a thicker client approach, which the more abstract object playback provides, depends on how you want to conduct stress tests. Usually, it's best to have both methods available. If you just want to blast virtual users at your site and you don't care much about whether cookies or session IDs work, or whether the Web application is returning all the correct data, then a thinner client approach may be adequate. But when you want to make sure the functional aspects of your site are working correctly while it's being stressed, the thicker client offers better data validation and better support for the client-side interactions mentioned above.

It would be ideal to have a real workload to stress your Web application, but these products are only capable of creating an artificial workload. There's no way to correlate an artificial workload accurately, no matter how carefully it's produced, with real user workloads, but these products help you simulate real workloads. One way they do this is by letting you insert "think" times, which are the pauses that real users frequently make when they're visiting Web sites.

A method to create more-realistic workloads is to analyze your Web server or application server logs using a Web-log analysis tool to discover the most common user paths through your site. You can then try to recreate those paths manually when creating your workload.

To test the three products, we used some development facilities at Living.com Inc., an E-commerce site that sells furniture and other household goods. The development systems we used ran a sample Web application under Art Technology Group's Inc.'s Dynamo 4.1 application server and used Netscape Enterprise Server as the front-end Web server.

The test controller machine was a Dell Computer Optiplex with 256 Mbytes of RAM and a 400-MHz Celeron processor, running Windows NT 4.0. The load-generation system was a Dell PowerEdge 2300 with dual 450-MHz Pentium II processors and 512 Mbytes of RAM, also running NT 4.0. The sample Web application is a three-tier system running the Web and application servers on Sun Sparc systems under Solaris and an Oracle database under Linux.

continued...page 3, 4
return to page 1