ArsDigita Traffic Jamme
Part of the
ArsDigita Server Architecture
This page was last updated on April 5, 1999
One of the more common requests to float across the world is "How do I
apply a heavy load to my server for testing purposes". Simulating
heavy traffic is easy. Simulating heavy traffic
well
is a hard problem.
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.
Installing ArsDigita Traffic Jamme
Running a simple test
- Visit /tj/index.tcl on your server
- Enter the URL you wish to pummel, the number of
simultaneous threads (connections) to use, as well as the number
of times each thread should request that URL
- run the test and evaluate the results
Running a CSV test
Just hammering the same URL over and over isn't necessarily all that
interesting. You can also supply a comma-separated-value (CSV) file
that specifies the URLs to fetch, along with any form data you wish to
pass along. A sample CSV file is provided in the Traffic Jamme
distribution.
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.
- Create your CSV file locally using whatever tool you want to use
- Visit /tj/index.tcl on your sever
- Choose your CSV file
- Enter the URL the number of
simultaneous threads (connections) to use, as well as the number
of times each thread should request an URL. (the URLs are chosen
randomly from the set supplied in the CSV file)
- run the test and evaluate the results
Writing your own test
- Decide what you want to do and what data you want each test to
run (say you're running a POST test and you want to communicate
the form variables)
- Write the HTML form to get the data from the user and have the form
invoke a Tcl script
- create a worker script that kind looks like this:
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.
- Output any kind of window dressing for the page
- call
tj_run_test $thread_count $iteration_count $interval $worker_script
(assuming you've set thread_count, iteration_count, and interval to
something useful)
- output any kind of mop-up content for the page
- See
calibrate.tcl, test-run.tcl,
post-test-run.tcl, or csv-run.tcl for examples
Random Notes
- You don't want to run a Traffic Jamme test from the same AOLserver
process that you're load-testing, and you shouldn't run it on
the same machine as the web server that you're testing.
Known Problems
- The 'allow only one test to run' stuff doesn't work
Future Directions
- Add support for cookies and arbitrary headers
- Slurp target URLs from a database
- Make it less 'nice' (see above)
- Add smarts to allow requests to depend on the previous requests
Other Tools
- The Ars Digita Site Profiler provides some of
the features mentioned above (cookies, requests that depend on
previous requests)
markd@arsdigita.com
