Load Testing using The Grinder

Introduction

The Grinder is an open source load testing tool. The Grinder uses Jython scripts and the scripts are executed using agents which can be distributed over the network. Property file is used to define tests and load.

The Grinder framework comprises three types of process or programs;

    1. Worker Process: Interpret Jython test scripts and perform tests using a number of worker threads

    1. Agent Process: Manage worker processes

 

    1. The Console:
        1. Coordinate the other processes
        1. Collate and display statistics
        1. Script editing and distribution

 

 

Configuration

We will create a couple of batch files to conveniently start up the agents and console.

    1. Extract the zip file and copy at any location. E.g. C:\grinder
    1. First batch file “setgrinderenv.bat” will have following commands.

set GRINDERPATH=”C:\grinder”

set GRINDERPROPERTIES=”C:\grinder\grinder.properties”

set CLASSPATH=%GRINDERPATH%\lib\grinder.jar;%CLASSPATH%

    1. Second batch file “startconsole.bat”

call “C:\grinder\setGrinderEnv.cmd”

java -cp %CLASSPATH% net.grinder.Console

    1. Third batch file “startagent.bat”

call “C:\grinder\setGrinderEnv.cmd”

java -cp %CLASSPATH% net.grinder.Grinder %GRINDERPROPERTIES%

How to update Property file?

The load test is defined using the property file. The configuration entry grinder.script = http.py indicates the path of the Jython script which will be run. Other interesting configurations include the number of processes created by each agent (grinder.processes) and the number of threads for each process (grinder.threads).

I would also recommend to explicitly specify the log and the temporary directories:

# The directory in which worker process logs should be created.

grinder.logDirectory = log

 # Additional arguments to worker process JVMs.

grinder.jvm.arguments = -Dpython.cachedir=”C:\\ grinder\\tmp”

The Test

The load test can be written manually or can be generated through the TCP proxy provided with The Grinder.

Starting the TCP proxy to generate the load case could be done through yet another batch file:

“Tcpproxy.bat”

call “C:\grinder\setGrinderEnv.cmd”

java -cp %CLASSPATH% net.grinder.TCPProxy -console -http > proxy-output.py

When TCP Proxy is started, display the following information:

Initializing as an HTTP/HTTPS proxy with the parameters:

Request filters:  EchoFilter

Response filters: EchoFilter

Local address:    localhost:8001

Engine initialised, listening on port 8001

This indicates that the TCPProxy is listening as an HTTP proxy on port 8001 (the default, but you can change it with -localPort).

Preparing the Browser

In the browser options dialog, set the proxy host to be the host on which the TCPProxy is running and proxy port to be 8001).    Run through your test scenario on your website. Having finished your run through, press “Stop” on the TCPProxy console and the generated script will be written togrinder.py.

The grinder.py file contains headers, requests and a logical grouping of requests into pages, of the recorded tests.

Once you’ve recorded your script you have two methods that you can use to replay your script:

    1. You can create a simple grinder.properties file and you can replay the recorded scenario with The Grinder. Your properties file should at least set grinder.script to grinder.py.
    1. Alternately you can use the console to distribute your script to an agent and set it as the script to run. Each agent will still need a simple grinder.properties file containing the console address, though you will not need to set the grinder.script property.

Will be continued….

 

Leave a Reply

This site uses Akismet to reduce spam. Learn how your comment data is processed.