Updated 2012-07-06 17:19:42 by RLE

Here's yet another tcl web-load tester, inspired by the torture script in the tclhttpd distribution. It allows you to send requests to a webserver either at a constant rate or as fast as the server can handle them. Its too slow for benchmarking (I can only get it to send a few hundred requests a second) but somewhat useful for real-world tests where a web app may only be able to handle a few dozen hits a second but that's all that will ever be needed.

That characterization of 'too slow for benchmarking but fine for the real world' seems rather appropriate to tcl. It also goes to show how nice the tcl event loop is; I'd expect threads to be the first resort in many languages but they're not really necessary.

Behavior should be fairly self-explanitory. Enter a url with an optional parameter (indentified with %1) that will be expanded on each request to one of the values from the list. Using different parameters may reduce the effectiveness of caching and simulate a more real-world hit pattern.

Performance isn't as good as I'd like, particularly the constant-load operation where I think it will stop issuing requests against a fast server sooner than it should. Any improvements are welcome.

Possible enhancements are better interfaces to parameters (load from a file?) generate reports, graph response times, or make whatever pretty pictures are needed to impress the suits.

As with any web tester, be careful if you're testing a forking webserver, as its pretty easy to drive the load through the roof. With constant-load operation this is less of a problem.

In the Half Bakery: [1]

The gui version should be straightforward.

The command-line version (cltest.tcl) is run as
 cltest.tcl url load/rate count/time { params { headers ... }}

  • url is the url to test against, with @1, @2, etc acting as placeholders for variable parameters
  • load/rate is the speed to test at. If positive, it is the load (concurrency) to run the test at. If negative, it is the constant number of requests to issue every second at a constant rate.
  • count/time is the duration of the test. In positive, it is the number of requests to issue. If negative, it is the time in seconds to run the test for.
  • params is a list of parameter values for substituting into the url (e.g., for running a search with varying search terms)
  • headers is a list of http headers to add onto each request, e.g., for a login cookie.