About
Documentation
Community
|
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 / seconds. After seconds have elapsed, all threads will be running.
|
|
|