ArsDigita Archives

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

  • Acquire Philip Greenspun's AOLserver utilities and place them in your AOLserver shared Tcl directory

  • Download tj-0.1.tar.gz and extract the contents into a server's page root.

  • Extract the contents into the pageroot

  • Copy httpopen.tcl and tj-defs.tcl to your AOLserver private Tcl directory. (they can go into your shared Tcl directory instead, if you want)

  • If you're not running the ArsDigita Community System, you'll need to copy util-extra.tcl to your private (or shared) Tcl directory

  • Edit your AOLserver configuration and make sure that this is set:

    (you may want to add index.tcl to the DirectoryFile entry as well)

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)