Home

Awesome

Blueflood Grinder Integration <a href="https://github.com/rackerlabs/raxmetrics-perf-test-scripts"><img src="https://assets-cdn.github.com/images/modules/logos_page/GitHub-Mark.png" height="32" width="32"/></a>

Intro

Grinder is a distributed load testing tool described here

This code defines implementations of grinder worker threads meant to repeatedly invoke the required number of BF api calls during each "reporting interval"

It also includes the infrastructure to divide the total work described in the grinder properties file across all the workers in the distributed system.

Architecture

The BF grinder system is designed to take a single properties file that lists the total number of threads to be used to generate load, and allocate each of those threads to generate a certain kind of http request.

The BF grinder code creates different types of threads to handle the different kinds of requests to be generated. Currently the thread types are:

The grinder.threads property determines the number of threads started by each worker process. How those threads are divided up between the different *Thread classes is determined by weight properties. A given thread type will be created for a number of threads proportional to the weight specified for that thread type divided by the total weight for all thread types.

Each thread generates one HTTP request for each "run" of Grinder.

Properties that control operation

Grinder-specific properties are discussed in more detail here

Installing

Optional - with Docker

For a quick, self-contained environment, run this project in Docker. Start by building the image and running it:

docker build . -t bf-perf
docker run --rm -it --name bf-perf bf-perf

Then treat it like a virtual machine that you log into with docker exec:

docker exec -it bf-perf bash

Be sure to set Blueflood URLs as appropriate in the properties file so that the container can reach it.

Note: This image has the source files copied into it, not mounted, so changes to the source aren't reflected in your running container. If you make changes, make them in the container, or else you have to rebuild the image and start a new container.

Optional - without Docker

The following command will download the necessary software packages and place them under the dependencies/ folder:

./setup-dependencies.bash

Note this needs to be run on each node in the cluster, as well as the console.

Starting the console

The GUI can be started with the provided script:

./run-console.bash

The console can also be run headless, with another provided script. You'll need to use this one if you're using Docker:

./run-headless-console.bash

The headless console starts in the foreground and will give a few lines of output when started successfully, including successfully starting a Jetty server. To control the headless console, you can interact with a rest api like so:

curl -X POST http://localhost:6373/agents/stop-workers
curl -X POST http://localhost:6373/agents/start-workers

Once the tests are started, the console terminal keeps outputting "collecting samples" every second, even when no tests are currently running. Grinder writes test output to log files in resources/logs by default (overridable in the properties file).

If you see connection errors in the logs, make sure the blueflood URLs set in the properties file have the correct IP and port for wherever you have Blueflood running.

The graphical console gives some useful status info, so you may prefer using that.

Starting the agents

Each agent is started with the provided script, like so:

./run-agent.bash $GRINDER_PROPERTIES_FILE

There are currently some example properties files in the properties folder:

  1. grinder-local.properties has some configs for running on your localhost
  2. grinder-unittests.properties holds the configs used by the unit tests

The agent is headless and starts in the foreground. You'll see a few lines of output on a successful start, including a line indicating that it's waiting for the console.

Coverage

There is a set of unit tests to check the function of the individual components in the scripts. The relevant file is scripts/tests.py. To run the unit tests under Jython and Grinder, you can simply run ./run-unit-tests.bash at the bash prompt. Alternately, there is a ./run-unit-tests-with-coverage.bash command that will run the unit tests under Python, collect code coverage numbers, and produce a report at htmlcov/index.html.

Todo