Next Previous Contents

3. QuickStart

This chapter provides a quick introduction to the WebLoad tools, concepts and procedures. It should get you up and running quickly without having to read a lot. For more complete information, please follow industry standard RTFM procedures.

3.1 Intro

WebLoad is a http server performance measurement tool suite. In typical usage, there are three phases to using WebLoad:

  1. Collecting and recording a "session" (a sequence of URL's) based on an actual tour of a web site with a browser,
  2. Using the session file to make single-user statistical & performance measurements,
  3. Using the session file to emulate a load of tens or hundreds of users actively accessing the web site.

WebLoad can also be used in other ways, such as collecting detailed traces of actual HTTP traffic, periodically "pinging" a server to see if its alive, checking up on site response times, validating web pages.

3.2 Prerequisites

The WebLoad tools have been compiled and run under a variety of Unix's, as well as Win95 and WinNT. The current distribution has only been tested under Linux, although ports to other platforms should be easy.

Note, however, that not all features are available under 95/NT (due to MS limitations). The multiuser tools cannot be made to work on NT/95. The data analysis scripts require perl to be installed, however, without the tools, there's no data to analyze ...

3.3 Collecting a Session File

A sequence of URL's representing a user's session with a browser can be collected with the webmon tool. The webmon program acts as an HTTP proxy in that it listens for and accepts connections from a web browser, and then forwards the actual URL requests to the true destination. It will record the requests that it receives in a session file that can later be "played back" with the webclient tool.

The webmon tool takes a number of command line parameters that must be specified in order for the tool to work; these parameters include the port number to listen on, the name of the session capture file, and whether, and what kind of SSL encryption should be used.

Rather than typing in all of the required command-line parameters, it is easiest to run webmon from a shell script. An example AIX script is provided in examples/run.webmon; the Windows 95 equivalent is the batch file examples/webmon.bat. You should make a copy of this file, and edit it to suit your tastes and particular setup.

To collect a session log, simply start run.webmon, and then configure your browser to use webmon as a proxy. To do this, you will need to find the Preferences menu entry for your browser. For example, for the Netscape browser, follow the menu entries Edit...Preferences... then choose Advanced...Proxies and select Manual proxy configuration...View.... You will see a dialog window with a number of blanks, including two labeled HTTP Proxy and Security Proxy. Type in the name of the host on which you plan to run webmon; and use 5080 (the default webmon port number) as the port. Leave the field for the SOCKS Host blank. Then click on OK to complete the changes.

You can now use the browser as you ordinarily would, visiting whichever sites you please. Webmon will record and trace your activity. To stop webmon, just kill it. It cleans up automatically.

Be sure to clear your browser's cache before starting. If you've been previously surfing a site before you turn on webmon it is likely that your browser will work with pages taken from the browser's cache, rather than sending new requests to the server. If the browser doesn't contact the server, then webmon can't record the traffic. What it will record will look fragemented and confusing.

Webmon will create a file that resembles examples/http.requests, while the messages written to the screen should resemble examples/webmon.out.

3.4 Collecting Traces

webmon can be used to collect raw http traces, showing all requests and responses. Tracing is enabled by specifying the -t flag followed by the file name where the trace should be written. You can selectively trace only the client requests, or the server responses, by using the --trace-client and --trace-server flags.

3.5 Performing a Single-User Run

After a URL trace has been collected, the webclient tool can be used to collect single-user timing statistics. It will take a session of URL's recorded with webmon, and play them back in order, measuring a variety of statistics for each URL. To obtain a good sampling of average statistics, it can be made to replay the session over again multiple times. To better simulate an actual user, it can be made to pause between each fetch.

Webclient supports a number of optional features. Among these are:

The best way to create a list of URL's for the webclient program is to modify the output trace of the webmon proxy server. The sequence of requests to be played back must delimited with a <<START>> tag. This tag is automatically written by webmon. The end of the sequence of requests must be delimited with the <<END>> tag, followed by two numbers: the count and the think time. The count is the number of times that the session should be run. The think time is the number of seconds to pause between each request. A zero think time causes the webclient to replay the requests as quickly as it can; a non-zero value causes webmon to pause between requests, emulating a user reading and thinking about a web page, before moving on to the next request.

To further simulate a realistic setting, the think time can be handled on one of two ways: either as a fixed length of time to wait, or as a random amount of time to wait, where the average of the random times is specified. To get get webclient to use fixed length pauses, specify the think time as a *negative* value. Webclient will pause minus the specified number of seconds. To get randomized pause intervals, specify the think time as a positive quantity. The average length of the pause will then be the specified think time.

Webmon automatically writes out the <<END>> tag, like so:


   
<<END>> COUNT MEAN_THINK_TIME

This needs to be edited to look more like so:

   
<<END>> 5  12.6

which specifies five repetitions of the session, and an average pause of 12.6 seconds.

An example input file can be found in examples/webclient.input, which is just a modified version of the file examples/http.requests which was generated by webmon. The output report that results from running webclient can be seen in examples/webclient.report. In order to simplify the running of webclient, the shell script examples/run.webclient can be modified and used to run webclient. It documents some of the more basic flags that are used with webclient; for a full description of the webclient parameters, refer to the webclient documentation.

3.6 Performing a Multi-User Run

Performing accurate multi-user performance measurements is harder than merely starting 25 copies of webclient within a single shell script. This package includes several utilities to simplify the process. Foremost is the script run.workload. It performs one important, crucial function: it synchronizes the clients so that none of them are making performance measurements until all of them have started. This is vital for getting accurate measurements, as the ramp-up times for starting dozens of clients can take dozens of minutes, and the CPU, network, paging-space usage will vary wildly during ramp-up. In addition, one typically wants to start the clients in a staggered fashion, so that they are not all fetching the same pages at the same times. The run.workload script provides both this synchronization, and the staggered startup.

The run.workload script also simplifies measurements if multiple servers need to be loaded simultaneously. It also provides facilities for specifying multiple, unique logins & passwords for each client.

Briefly, take the following steps to do a multi-user run:

3.7 Accessing External Hosts from Behind a Firewall

There are many different types of firewalls; the mechanism used to get access to the outside world depends on the type of firewall. You should consult with the local sysadmin to find out what kind of firewall you have. WebLoad supports three styles of firewalls: NAT/Masq, Proxy, and SOCKS.

If you are reading this, you probably don't have a NAT/Masq firewall, as this would be completely transparent to you, and you wouldn't know that you were behind a firewall.

If you have a choice between a Proxy and SOCKS firewall, the Proxy is recommended. This is because the Proxy is much easier to configure, and the code/implementation is simpler, more robust, and less prone to unpleasant surprises. SOCKS may yield slightly better performance, maybe.

NAT (Network Address Translation) / Masquerading Bastion Firewalls

These should be completely transparent to clients behind the firewall. All of the WebLoad clients should "just work". If they do not, check that the default route (the route for all external IP packets) is aimed at the firewall. If the route (netstat -r) appears OK, then check with the firewall admin that port 80 and/or port 443 (the SSL port) have not been filtered or disabled.

Proxy Servers

Proxy Servers are a special kind of a webserver designed to relay HTTP traffic between the internal, protected network and the external world. Proxy servers are typically installed on the bastion host, and are typically configured to listen to port 80 or 1080 for HTTP traffic.

The two clients webmon and webclient can chat proxy-HTTP with proxy servers. Simply specify the proxyhost:portnum with the -P flag (capital P flag).

If you are able to access ordinary web sites, but not SSL-secured websites with the -P flag, then please verify with the sysadmin that the proxy understands the CONNECT protocol, and that it is configured to allow CONNECT's.

SOCKS Bastions and Gateways

SOCKS-based firewalls require specially-modified clients and special configuration files.

SOCKS Unix Instructions:

The "r" versions of the clients: rwebmon and rwebclient, are special socks-ified versions of the usual clients that know how to get through a SOCKS-style firewall. They do require special configuration.

There must be a properly configured socks client file in /etc/socks.conf. This file must be installed by root. A sample socks.conf file can be found in the examples directory. This file specifies which IP addresses lie behind the firewall, which ones are external, and how to route external addresses to the appropriate SOCKS server. Ask the sysadmin to help setup and configure the /etc/socks.conf file.

Alternately, a socks server can be specified with the SOCKS_SERVER environment variable. For example, for the machine soxy.lady.com has a SOCKS server configured to listen to port 1080, then try


export SOCKS_SERVER=soxy.lady.com:1080   # in sh/bsh/bash/ksh

setenv SOCKS_SERVER soxy.lady.com:1080   # in csh/tcsh

SOCKS Windows95 or Windows NT Instructions:

There are several packages available for Win95 that implement the SOCKS package. Two of note are the NEC SocksCap package, and the Hummingbird SOCKS package. It appears that the NEC package will not inter-operate properly with some SSL libraries used by the WebLoad software, causing Win95 to lock up hard. The Hummingbird package appears to work quite well. The instructions below detail installation & operation of the Hummingbird package.

The Hummingbird package is available free-of-charge at http://www.hummingbird.com/products/socks/ It is also accessible through http://www.hummingbird.com/freestuff.htm The license appears to be fairly unencumbered & does not seem to in any way restrict use.

Hummingbird Installation Instructions

  1. The download file is called socksx86.zip
  2. unzip it in directory C:\EXCEED\SOCKSX86
  3. While running Win95, open a DOS shell.
  4. Run .\INSTALL.BAT at the command line
  5. Warning: double-clicking on the INSTALL.BAT icon from the Win95 file browser will cause installation to fail. It will *NOT* install this way. It MUST be run from the Windows shell command line. Furthermore, this must be done from a DOS shell opened while Win95 is running. It will not install properly if Win95 is not running.
  6. Edit C:\WIN\SYSTEM\SOCKS.CNF This file uses the same format and syntax as the Unix /etc/socks.conf file; so if you have one handy that works well, just copy it to C:\WIN\SYSTEM\SOCKS.CNF Otherwise, edit this and add a line similar to the following:

       SOCKD4 @=9.3.199.116 0.0.0.0 0.0.0.0
    

    The first number is the IP address of your socks server. The second two numbers are masks. In this example, the masks are set so that *all* IP traffic to & from your box will go through the the socks server, even if its internal traffic. You may want to change this so that internal traffic does not go through socks.

That's it.

After installing Hummingbird SOCKS, note that *all* TCP/IP applications are socks-ified, and get access to the external world. In particular, Netscape and MSIE will both access the external world, even if they are configured with proxy turned off. (i.e. configured for direct connection to the Internet).

The webmon and webclient exe's have been tested and work just fine with the Hummingbird socks package.

The NEC SocksCap Package

The following instructions are xxxx'ed out because the SocksCap package causes Win95 to lock up hard when used with these clients on my machine. You may have better luck, and so I left these instructions in. Note that the Hummingbird SOCKS package described above does work.

Installing SOCKS for Win95/NT:

  1. Go to http://www.socks.nec.com/
  2. Download SocksCap for Win32
  3. Run sc32r103.exe (the setup file)
  4. Start SocksCap (sc32.exe)
  5. Choose config from the menu, setup your socks server and port user: your name protocol: socks 4 or socks 5 (probably socks 4 at most sites)
  6. Create a new "application profile"; add the name of your application and its working directory
  7. Start the application from the SocksCap control panel by double-clicking

To run a program under SocksCap from the command line or a batch file:


C:\fullpath\to\sockscap\sc32.exe c:\fullpath\to\your\app  -flags -for -your-app


Next Previous Contents