Each of these processes is a Java Virtual Machine (JVM) and can be run on any computer with a suitable version of Java installed.

To run a given set of tests, an agent process is started on each test-client machine. This process is responsible for creating a number of worker processes. Each loads a plug-in component that determines the type of tests to run and then starts a number of worker threads. For example, with the provided HTTP plug-in each test corresponds to an HTTP request to a URL. Each of the worker threads uses the plug-in to execute tests.

The grinder.properties file is a configuration file that is read by the agent and worker processes, and the plug-in. This file contains all the information necessary to run a particular set of tests, such as the number of worker processes, the number of worker threads, and the plug-in to use. For most plug-ins, the file also specifies the tests to run and can be thought of as the "test script." For example, when using the HTTP plug-in, the grinder.properties file contains the URL for each test.

The agent process and the worker processes read their configuration from grinder.properties when they are started (see Figure 1). I usually put the grinder.properties file on a shared network drive so I don't have to copy it to each of the test-client machines.

The net effect of this scheme is to allow the easy configuration of many separate client contexts, each of which will run the same set of tests against your server or servers. Each context simulates an active user session. The number of contexts is given by the following formula:

(Number of agent processes) x (Number of worker processes)
x (Number of worker threads)

The Console
The Grinder console (see Figure 2) provides an easy way to control multiple test-client machines, display test results, and control test runs.

The console is used to coordinate the actions of the worker processes by sending them start, reset, and stop commands. IP multicast is used to broadcast the commands simultaneously to processes running on many machines. The worker processes send statistics reports to the console, which combines these reports to produce graphs and tables showing test activity. The results of a particular test run can be saved for further analysis.

The console also calculates and displays derived statistics. A key derived statistic that the console can calculate, but the individual worker processes cannot, is a combined transactions per second (TPS) figure for all the worker processes. This is because a rate, such as TPS, can't be calculated without a shared notion of the beginning and the end of the timing period. The console performs the required timekeeping function.

Getting Started
Have I whetted your appetite? Let's try running The Grinder. In this example, we'll start both the console and an agent process on a single machine.

Having expanded The Grinder distribution and set up your CLASSPATH appropriately (see the README file provided with The Grinder for details), you can start the console with the following command:

$ java net.grinder.Console.

The console window should appear. Now change to a directory to hold the output of the worker processes and create a grinder.properties file:

grinder.processes=2
grinder.threads=5

grinder.plugin=net.grinder.plugin.http.HttpPlugin

grinder.test0.parameter.url=\
http://e-docs.bea.com/wlsdocs70/index.html
grinder.test1.parameter.url=\
http://e-docs.bea.com/wlsdocs70/images/bealogo.gif

This particular file specifies that there will be two worker processes with five worker threads each, and that the HTTP plug-in will be used. It also defines two tests that involve accessing resources from the BEA e-docs site.

Start the agent process in the same directory as the grinder.properties file :

$ java net.grinder.Grinder

The console display will update to show the two tests. To instruct the worker processes to start the test run, select Start processes from the Action menu. After a short delay, the console display will show graphs of the incoming reports.

Individual graphs will show the TPS for each test, and a full graph will show the total TPS. Alongside each graph, the mean transaction time, mean transactions per second, peak transactions per second, number of transactions, and number of errors recorded for each test are shown. The colors of the individual test graphs vary from yellow to red to indicate the tests that have the longest mean transaction times. The more red a test graph is, the longer the transactions for that test are taking.

Try selecting the Results tab to see the results in a tabular form. You can also select the Sample tab to show the sum of all reports received during the current console sample interval.

Note: If this example doesn't work the first time, it's usually something straightforward. Have a look though the documentation that comes with The Grinder, and if that doesn't help you, e-mail grinder-use@lists.sf.net.

Recording Test Scripts
It's quite feasible to have HTTP plug-in grinder.properties test scripts containing hundreds or thousands of individual tests. The Grinder lets you specify the timing of each test. Additionally, the HTTP plug-in provides support for setting cookies, authentication information, dynamically generated requests, HTTPS, and other HTTP features. All of these are configured using properties in the grinder.properties file.

Writing such test scripts by hand quickly becomes impractical. The Grinder is shipped with a tool, the TCP Sniffer, that can automatically capture test-script entries corresponding to the HTTP requests a user makes using a browser, and generate corresponding test-script entries. The TCP Sniffer is configured to sit between the user's browser and the target server and capture all the requests the browser makes before proxying the requests on to the server. (Technically the TCP Sniffer is a proxy and not a sniffer at all, but it's very useful despite being misnamed!) The responses the TCP Sniffer receives from the server are returned to the browser.

You can start the TCP Sniffer in a special mode in which it outputs a recording of the requests you make with the browser as a full grinder.properties test script. You can then take this test script and replay it using The Grinder.

More Than HTTP
While the HTTP plug-in is the most commonly used, The Grinder can also be used in contexts other than Web and Web-services testing. Two other example plug-ins are shipped with The Grinder, a JUnit plug-in that allows you to repeatedly exercise a JUnit test case using many threads, and a raw socket plug-in.

It's also easy to write your own plug-in - you just provide a Java class that conforms to a simple interface. I often do this to test J2EE applications with EJB or a JMS interface.

The Grinder is already a powerful tool, but it can be improved. One of the key limitations is that each worker process executes the tests in the test script sequentially, in a fixed order. The Grinder 3 will address this by allowing tests to be specified using a variety of scripting languages, including Visual Basic, Jython, and JavaScript. Test scripts will allow arbitrary branching and looping, perhaps using the scripting languages' support for random variables. That's if I can find the hacking time.

Happy grinding!

Acknowledgements
I am grateful to Tony Davis and the Expert Press team for their permission to use material from J2EE Performance Testing. As well as full coverage of The Grinder, this book contains much practical information about J2EE performance and application benchmarking.

I also wish to express gratitude to VA Software for the SourceForge site (http://sourceforge.net/). SourceForge is without doubt a great resource for the open source community and is responsible for the continued success of The Grinder and many other open-source projects.