Mite

Load Testing Framework

Mite is a load testing framework with distributed components written in Python. Requests are executed asynchronously, allowing large throughput from relatively small infrastructure.

Installation

pip install mite

This requires that you have libcurl installed on your system (including C header files for development, which are often distributed separately from the shared libraries). On Ubuntu, this can be accomplished with the command:

sudo apt install libcurl4 libcurl4-openssl-dev

(NB we recommend using a version of libcurl linked against openssl rather than gnutls, since the latter has memory leak problems)

You can also use the dockerfile included in this repository to run mite. In order to get a shell in a container with mite installed, run these commands (assuming you have docker installed on your machine):

docker build -t mite .
docker run --rm -it mite sh

Run mite --help for a full list of commands

Optional install extras

pip install mite already installs every integration mite ships. The extras below are installable labels only, added ahead of a future major release that will actually make them optional. Today, installing any of them (or none) installs exactly the same packages:

pip install 'mite[kafka]'
pip install 'mite[all]'

(quote the brackets so your shell doesn't treat them as a glob)

This list doesn't include playwright, otel, influxdb, or dev. playwright needs a separate playwright install step to download browser binaries so it isn't installed by any extra; otel, influxdb, and dev are separate, pre-existing extras unrelated to this list. Every extra above is currently a functional no-op: all of their packages are still in mite mandatory dependency list, so pip install 'mite[kafka]' installs exactly what pip install mite installs. They only become meaningful once a future major release actually removes packages from the default install.

Your first scenario

Scenarios are a combination of 3 things, a set of journeys to run, a datapool to provide test data for the journey (if applicable), and a volume model.

Journeys

Journeys are async python functions, and are where you put the logic of what you're trying to achieve. Below is a simple example:

import asyncio

async def journey(ctx, arg1, arg2):
    async with ctx.transaction('test1'):
        ctx.send('test_message', content=ctx.config.get('test_msg', 'Not set'), sum=arg1 + arg2)
        await asyncio.sleep(0.5)

This journey just sends a log message to be collected by the framework and waits for half a second. This journey takes 3 arguments, a context and two numbers (which will be supplied by the datapool, see below).

Context

The context is important for every journey. It provides a number of useful methods for timing/naming of transactions, sending messages and defaults to including http functionality from acurl. Functionality can be included in the journey by attaching it to the context.

In the above example we see an example of naming a transaction async with ctx.transaction('test1'):. This will capture timing for the indented block.

We also see that the config is attached to the context with ctx.config.get('test_msg', 'Not set') and in this case, the value of that config value is sent to the log collector with ctx.send('test_message', content=ctx.config.get('test_msg', 'Not set'))

Datapools

To feed data into your test journey, you'll need a datapool. Several of these are already provided in mite and usually read data in from an iterable. To specify a custom datapool implementation, you simply need a class that implements a checkin method which adds data to the pool and a checkout method which removes data from the pool to be used by journeys.

For the above journey, which expects two arguments, we will show an example of the RecyclableIterableDataPool.

from mite.datapools import RecyclableIterableDataPool

datapool = RecyclableIterableDataPool([(i, i+2) for i in range(5000)])

This pool will share data out to runners and check it back in when the runners are done with that block of data. In this case it cycles through a list of tuples which each contain two integers.

Volume Model

A volume model defines how many instances of the journey should be ran within a window of time. The window is definied as a start and an end time (measured in seconds since the beginning of the test), which will be fed to the model by the framework. This allows complex calculations to specify the current volume based on the current time. The volume model can also raise StopVolumeModel to inform mite that the load injection should stop for a given journey. For this example we'll use a simple volume model which merely runs ten journeys simultaneously, forever.

volumemodel = lambda start, end: 10

Scenario

We now need to package the journey, datapool and volume model into a scenario. This is a simple as defining a function which returns a list of triplets of (journey name, datapool, volumemodel).

def scenario():
    return [
        ['mite.example:journey', datapool, volumemodel],
    ]

The journey name should be a string with two parts separated by a colon. The first part is the name of a python module that is importable; the second is the name of a journey (an async function) within that module. It is necessary to specify this as a string, rather than as a python object, because the journey will be executed in a different python process than the scenario function is. Thus, we need a name for the journey that allows any python process to find it.

The volume model and data pool, on the other hand, are only used in the python process where the scenario function runs. They are both python objects.

Testing the journey

Before running the scenario, we should test the journey in isolation as a scenario can be made up of multiple journeys. This can be done with the mite journey test command. We just need to pass the name of the journey and the datapool it requires:

MITE_CONF_test_msg="Hello from mite" mite journey test mite.example:journey mite.example:datapool

If something goes wrong, adding the --debugging flag to this command will drop excution into a debug session. The choice of debugger used can be managed by setting the PYTHONBREAKPOINT environment variable before running mite. Python's built-in pdb) debugger is invoked by default, but this can be changed to use, say, the ipdb debugger:

pip install ipdb
export PYTHONBREAKPOINT=ipdb.set_trace
export PYTHONPOSTMORTEM=ipdb.post_mortem

PYTHONPOSTMORTEM is a mite-specific extension to PEP 553 which defines the PYTHONBREAKPOINT functionality.

Run the scenario

In order to run the finished scenario locally, which will include all the necessary fixtures, run the following command:

MITE_CONF_test_msg="Hello from mite" mite scenario test mite.example:scenario

Distributed deployments

In order to scale up miteʼs capability to inject load, you will need to run it as a distributed suite of components. You can learn more about how to accomplish this in the documentation.

Deploy distributed mite with docker compose

Build mite image:

docker build -t mite .

Run mite deployments:

Use make from mite/local dir:

make up # start mite containers
make status # check status of mite containers
make clean # remove all mite containers

or

docker-compose -f docker_compose.yml up

For more information on distributed mite usage, info

Maintainers

If you run into any trouble or need support getting to grips with Mite, reach out on Slack if you work at Sky, or contact one of the maintainers if you're an external contributer:

Jordan Brennan 💻	Aaron Ecay 💻	Davide Annunziata 💻	Ryan Linnit 💻

Special thanks to the following contributors:

• Tony Simpson