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.
WebLoad is a http server performance measurement tool suite. In typical usage, there are three phases to using WebLoad:
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.
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 ...
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
.
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.
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.
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:
run.workload
, modify number of
servers, the host addresses and port numbers, etc. as appropriate.passwd
file, and add/change
any login names and pins/passwords as required.run.vmstat
on the server machine to get server CPU usage infocputotals
script to summarize stats about CPU usagesumstats
to boil down multiple client stats into a shorter,
more manageable collection.
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.
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 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-based firewalls require specially-modified clients and special configuration files.
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
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.
socksx86.zip
C:\EXCEED\SOCKSX86
.\INSTALL.BAT
at the command lineINSTALL.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.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 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:
sc32r103.exe
(the setup file)sc32.exe
)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