About

- Overview
- Download
- Changes
- Known Bugs
- License
- TODO
- Contributors

Documentation

- User Manual
- Developer Manual

Community

- Get Involved
- Mailing Lists
- CVS Repositories

ThreadGroups

> A ThreadGroup primarily holds controllers which deliver test cases to be tested. During test run, a ThreadGroup will iterate through all its controllers and extract test samples to execute. The order of iteration is determined by the order the controllers appear in the tree.

> Controllers can be nested, so the actual behavior of the iterative process can be arbitrarily complex.

> Additionally, ThreadGroups can have timers added to them. The timer will be used to create a delay between the execution of samples. Although multiple timers can be added to a ThreadGroup, there isn't much point to doing so. The timers delay values will simply be summed.

> Listeners can also be added to ThreadGroups. Listeners collect test data and do some useful function with the data, such as displaying the data visually (sometimes, such listeners are called visualizers). Other listeners save the data to file. Multiple visualizers can be added, allowing one multiple views of the data.

Logic Layering

> Probably the most important concept to understand is the layering of logic that occurs when a test script is compiled and run.

> A ThreadGroup holds Controllers (which you, as the user, have added to the ThreadGroup). During a test run, the ThreadGroup will go to the first Controller in the list, and will request a test sample (which it will then execute). This Controller, in turn, looks up its list of sub-controllers, finds the first one, and requests a test sample from it. This continues until there are no more sub-controllers, and a test sample is actually generated (generally by a sample generating controller ). This test sample is then passed along back up to the ThreadGroup, which made the original request, at which point it is executed. At any time, a Controller in this chain might report that it has reached the end of its test samples. Two things happen - first, the parent controller receiving this report will move on to the next sub-controller in its list, and two, the controller reporting this fact will re-initialize itself and be ready to start again if it is called upon again. Thus, when the ThreadGroup finishes with the last controller, it will start the whole process again with the first controller.

> Logic layering occurs because, as a test sample "bubbles" up through successive controllers on its way to the ThreadGroup, each controller it passes through has the opportunity to modify it. Each controller also has the opportunity to change the logical flow by behaving differently than what is described in the paragraph above. The Once Only Controller , for example, doesn't re-initialize after it has reached the end - it goes away, never to be repeated. The Interleave Controller , reports that it is done after every test sample (which causes its parent controller to "move on"). And, the Modification Manager examines every test sample that passes through it and potentially modifies it.

> Additionally, any config elements attached to a controller will be used to modify test samples that pass through that controller. The default behavior is that only blank fields within the test sample are filled in (in other words, data is never overwritten, but empty fields can be filled in). The value of this is that an entire test script can be generated, and the domain name of the server being tested doesn't have to be specified in each and every test sample. Instead, the domain name field can be left blank, and a UrlConfig element can be added to a top-level controller, or directly to the ThreadGroup itself, with only the domain name field filled in. Thus, the test script can be used to test multiple different servers with only a single change. Additionally, its always best to put the CookieManager element at the ThreadGroup level so that all test samples will share the same cookies.

Ramp-Up

> A ThreadGroup can have a ramp-up period associated with it, to provide a way to gradually increase the simulated load. The default value of the ramp-up parameter is zero. With this setting, the number of threads specified for the ThreadGroup are all started immediately when the test begins.

> If the ramp-up parameter is set to a value greater than zero, the threads are started one at a time, spaced evenly over the ramp-up period. The first thread is started immediately, at time=zero. After that, another thread is started every <rampUp> / <numThreads> seconds. After <rampUp> seconds have elapsed, all threads will be running.

Copyright © 1999-2001, Apache Software Foundation