Astra SiteTest

If your Web site is growing and you are concerned about performance, I know a product you need to consider. Mercury Interactive created Astra SiteTest to let Web masters stress test their Web site easily, with minimal testing resources.

Astra SiteTest is the easiest program I've used to test Windows NT Magazine's Web site. When I first launched the program, a start screen asked whether I wanted to use the scenario wizard, open an existing scenario, or create a new scenario. Because I hadn't used the product before, I chose the wizard, shown in Screen 1. The wizard lets you create a scenario in a four-step process: select the script, configure the number of virtual users, set rendezvous points, and determine transactions.

Creating a Script
If you don't already have a script, you can create a new one with the Virtual User Generator tool. To generate a test script, run Virtual User Generator from the wizard or the program group. When I launched Virtual User Generator, it started my browser and recorded the pages I visited and the actions I performed on each page. When I finished browsing, I simply saved the script. Using the interface is as easy as pressing Record on a tape recorder and then pressing Stop when you've finished recording.

This script is a text file, which you can easily edit with Microsoft Notepad. Each line of the script represents one of five types of statements: http get, rendezvous, transaction, FormSubmit, and server login. Http get is the most common statement and references each universal resource locator (URL) for the script to access. The script I used for my test is shown in Listing 1, page 122, which includes four of the five types of statements (the script does not use server login).

What Is a Vuser?
To understand user behavior at your Web site, Astra SiteTest lets you create virtual users (vusers) to simulate Web users. Vusers traverse the Web site simultaneously, but they don't stop and read--vusers just move from page to page. However, Astra SiteTest lets you create a think time for vusers to simulate users reading a page. I selected the range to be 0 milliseconds, which forced the vusers to go immediately to the next page without pausing, because I was more interested in pounding the server to see how it performed with an extreme load.

Choosing the number of vusers depends on several variables, because the number of vusers does not correspond directly to the number of real users. The amount of RAM on your test machine also plays an important part in the number of vusers you can run. Initially, I selected 30 vusers, but the test failed. I soon learned that each vuser needs about 2MB of RAM. Because I had only 64MB of RAM, I needed fewer vusers to allow for system overhead. I used 20 vusers to perform the final testing, which worked well.

Because of the lack of direct correspondence, I looked at my Web log to calculate what 20 vusers would mean in real terms. I analyzed the average response time, the average time spent between pages, the number of users on the site at a given time, and the number of simultaneous requests. I found that 200 real users create 1.5 to 1.75 simultaneous requests. This calculation means that 20 vusers equal 7000 real users (20 users * 1.75 requests * 200 real users).

Transactions and Rendezvous Points
The wizard lets you select which transactions to use and which rendezvous points are active. You must manually add rendezvous points and transactions to a script. Rendezvous points let vusers wait for other vusers to join them so that they can enter an area together, which creates a peak load on the server. You can disable or enable rendezvous points anytime during a test scenario, and you can set how many vusers will rendezvous.