This page was last updated on April 5, 1999
There are all sorts of benchmarking and load tools out there which can create lots of simultaneous connections and slurp down tons of data. It's also pretty easy to write your own.
It's very easy to run such a test like and declare "We can handle 100 simultaneous users and saturate our FDDI ring too". The main problem with tools like these is that they are too nice. They don't disconnect abnormally. They don't have high latencies and slow response. They don't tie up a web server connection for a couple of minutes. They don't send bad requests. They don't have truly random in-the-large behavior.(e.g. WebStone marches through a dozen URLs as opposed to a dozen Real People hitting your discussion group main page all at the same instant and your Illustra database deadlocks) The same system that easily handles hundreds of simulated users can fall over with 20 Real Life users.
So, have we solved all of these problems with ArsDigita Traffic Jamme? Nope. It's just a simple easy-to-write tool that creates lots of simultaneous connections that slurp down tons of data. Why write Yet Another Simple Tool? We wanted a tool that didn't require someone to compile (or port) a C program, that doesn't require Perl and Perl libraries, and one that works with AOLserver, since that's what we use around here. Also, in the future, we may want to have a tool with some intelligence that generates the next request as a function of the previous request, say to apply a load to a shopping service.
httpopen.tcl and tj-defs.tcl to
your AOLserver private Tcl directory. (they can go into your
shared Tcl directory instead, if you want)
[ns/server/server-name]
EnableTclPages=on
(you may want to add index.tcl to the
DirectoryFile entry as well)
Note, that if you want to run a CSV test, you'll need to have a
database configured as well. (this test relies on the
ns_getcsv call, which is only available if there is a
database available) This means you'll need [ns/db/drivers],
[ns/db/pool/pool-name], [ns/db/pools], and
[ns/server/server-name-db] entries. It's OK if the
number of connections allowed is zero and there's blank user and
password entries in the database configuration.
set worker_script {
ns_share count
ns_share iterations
ns_share mutex
ns_share test_url
ns_share the_form_vars
for { set i 0 } { $i < $iterations } { incr i } {
if [catch { set page [ta_httppost $test_url $the_form_vars] } ] {
# !!! need to report some kind of error
} else {
ns_mutex lock $mutex
incr count
ns_mutex unlock $mutex
}
}
}
The count, iterations, and mutex shared
variables are conveniences. The count value is what's
reported to the user as the test runs, and the mutex is there to
prevent concurrency problems from resulting in inaccurate results.
The body of the for loop is where you can do your interesting work.
tj_run_test $thread_count $iteration_count $interval $worker_script(assuming you've set thread_count, iteration_count, and interval to something useful)
calibrate.tcl, test-run.tcl,
post-test-run.tcl, or csv-run.tcl for examples