JStress is a lightweight performance harness written in Java. It is intended to be extended by developers, QA analysts, and anyone else with Java knowledge interested in obtaining performance metrics about a system. It seeks to be a useful tool to aid in analysis of the impact of changes made to a system.

Tasks

The TaskCase class is the heart of the JStress system. It is this class that the JStress developer extends to create performance tests. A TaskCase is simply an action with a timer measuring completion time of some task. Note that these tasks should be as discrete and simple as possible. To create a TaskCase in JStress simply:

1. Create a java class that extends jstress.task.TaskCase
2. Override the initTask(), runTask(), and destroyTask() methods
3. In the runTask() method specify the points to start and stop the Timer by using the startTimer() and stopTimer() methods respectively. (remember to put stopTimer() in a finally block

Multiple Tasks

If a series of steps must be performed as one conceptual request, you can use a Scenario. A Scenario is essentially a sequence of Tasks. Often times you will want to run a series of the same Task or a collection of different Tasks. A Scenario allows you to do this. A Scenario extends TaskCase. Thus, creating a Scenario looks exactly like creating a TaskCase with the following exceptions:

1. There is no need to override initTask(), runTask(), or destroyTask(). The defaults provided for Scenario iterate through all the Tasks and call their respective methods in sequence.
2. There is no need to explicitly call startTimer() and stopTimer(). These methods are called by the default runTask() method. However, you can override this if you so choose.

Note that wrapping HttpUnit in a TaskCase is also a valid approach to building up a suite to execute complex series of (stateful) steps. This approach will obviously be more robust.

Run Strategies

JStress allows the user to define not only the Tasks to be run, what other Tasks they should run with, but also the context under which they run. This is done through the use of a RunStrategy. The currently implemented run strategies are:

• BurstRun
• LinearRun
• LinearStepRun
• RandomRun
• SerializedRun

A RunStrategy determines the arrival rate, or attack strategy of requests against the system.

BurstRun

BurstRun is probably the easiest RunStrategy to understand. BurstRun takes in a single parameter; the number of instances to run. It then takes the requested Task/Scenario and clones it, running them in a separate thread for each requested instance. The tasks are all started simultaneously.

LinearRun

LinearRun is a RunStrategy that seeks to make the arrival rate constant. It does this by taking in two parameters: duration, and interval. It then fires off a new Thread every interval until the specified run duration time has elapsed. Both values are in milliseconds.

The arrival rate is defined as 1000 / interval. Thus, an interval of 100ms would give you an arrival rate of 10 requests a sec.

LinearRun is useful when the arrival rate needs to be kept contstant for long periods of time.

It should be noted that a task is started at every interval whether or not any previous request has completed. If the response time is typically 1 second, and the interval is 100ms, 10 requests will be started in the first second.

LinearStepRun

The LinearStepRun is similiar to the LinearRun, but it increases the arrival rate by increment every duration until the specified number of steps have completed or the interval end. This is the most useful run strategy. It allows you to build a profile of your system as the load increases.

RandomRun

The RandomRun simply randomly starts a new task somewhere between min and max until the task count has been reached.

SerializedRun

The SerializedRun strategy simply executes a series of tasks. As soon as the first task completes, the next begins. This is the simplest, if not least useful strategy.

Configuring Runtime Parameters

Currently the way that the runtime environment is configured is through the file jstress.properties. The file is located in the JStress root directory and specifies information about how each runStrategy will operate.