I've updated my sandbox with the latest loadtest module source. It's ready to use for anyone who wants to play around with it. The loadtest source is in contributions/sandbox/hadsie/loadtest.
The first part of this module lets you define and configure "states" for your site that you can run tests against.
Each state defines a set of modules and variables that will be enabled. When running a test you may select one of these pre-configured states to test against. The 'set to state' link sets the site to that state.
States can also be set remotely. This is useful for scripting load tests against your site. As an example, you could have a script as follows:
#!/bin/bash
curl http://localhost/drupal/admin/build/loadtest/set_state/test_state > /dev/null
ab2 -c1 -n500 http://localhost/drupal/index.php > test1a.ab
ab2 -c1 -n500 http://localhost/drupal/index.php > test1b.ab
curl http://localhost/drupal/admin/build/loadtest/set_state/test_state_nocache > /dev/null
ab2 -c1 -n500 http://localhost/drupal/index.php > test2a.ab
ab2 -c1 -n500 http://localhost/drupal/index.php > test2b.abThis script will automatically change the states as it runs and uses apache's benchmarking tool to run the test. Note that this script doesn't authenticate to Drupal at all, and so in this case 'anonymous' is actually setting up states. Obviously this is a major security risk and thus should not be used on production sites. There is a switch to enable and disable the setting of states by non-admin users.
admin/build/loadtest/set_state/on - enable state setting
admin/build/loadtest/set_state/off - disable state setting
The second part of the module lets an administrator run test within the drupal site.
Here you can give your test a name, select what kind of test you want to run and what state you want to use. These will generally run for several minutes, but depend on what tests you're running against your site. The default test suite runs tests against every module, automatically enabling and disabling modules at each test run so that it can test each module on it's own.
The results are displayed in a simple table.
As a module developer, you can also write your own test suites and load tests that will be used when running the load test module. Writing load tests is almost exactly the same as making writing simpletest tests. Except instead of inheriting from DrupalTestCase, inherit from DrupalLoadTest. This adds timing and logging to your test.
I've written two test suites thus far:
1. Individual Modules - tests each module on it's own.
2. Single run - Just runs a single test on the site, doesn't play with modules or settings.
To add your own, write a function that calls 'simpletest_run_tests' somewhere in it, and then use the loadtest_register_test_suite() function so that loadtest knows about your function. For example, loadtest does the following:
function loadtest_init() {
loadtest_register_test_suite("loadtest_test_single_run", "Single run");
}
function loadtest_test_single_run($tests_list) {
simpletest_run_tests($tests_list);
}Some of the modules most significant current limitations include:
* Browser may timeout when running the load tests as they could take a significant amount of time to run. I think some kind of ajax page loading trick might get around this.
* Currently there's just one test being executed (hardcoded), I'll need to add an interface that will let the user select the test they'd like to execute.
Still to come on the module:
* CSV output of data