Skip to content
Go to file

Latest commit


Git stats


Failed to load latest commit information.
Latest commit message
Commit time

MPT: messaging performance tool

Build Status

Linux Build Status: Linux Build Status

Coverity Scan: Coverity Scan Build Status

Codacy Report: Codacy Badge

Packaging Status

Fedora/RHEL/CentOS (GRU Testing): Fedora COPR (Testing Repo) Status

Fedora/RHEL/CentOS (GRU Stable): Fedora COPR (Stable Repo) Status


MPT is a tool for running performance tests on messaging systems. Current development version supports AMQP, STOMP and MQTT messaging protocols. Support for OpenWire and others is planned for the future. The test data is saved in a compressed CSV format.


The code can be installed via Fedora COPR. Packages are available for CentOS 7, Fedora 25 or greater and RHEL 7.


  1. Enable my testing COPRs.

dnf copr enable orpiske/orp-tools-testing dnf copr enable orpiske/third-party-tools-testing dnf copr enable orpiske/paho-testing

  1. Install the runtime only: dnf install -y msg-perf-tool

Note: the testing packages are the recommended packages for this project.


  1. Enable my testing COPR.

dnf copr enable orpiske/orpiske/orp-tools-stable dnf copr enable orpiske/third-party-tools-stable dnf copr enable orpiske/paho-stable

  1. Install the runtime only: dnf install -y msg-perf-tool


For building the project, the following dependencies are required:

To compile the project:

mkdir build && build

Note: development builds install files on /usr/local by default. Therefore, you need to adjust the LD_LIBRARY_PATH in the appropriate startup configuration files to point to /usr/local/lib64 (or any other directory set as the install prefix). The files that need to be set are:

  • Sender startup configuration: /etc/sysconfig/mpt-sender-daemon
  • Receiver startup configuration: /etc/sysconfig/mpt-receiver-daemon
  • Inspector startup configuration: /etc/sysconfig/mpt-broker-inspector


Disk Space: The clients may generate a lot of data depending on how much messages are sent per second. On my baseline system (two servers with Quad-Core AMD Opteron 2376 @ 8x 2.3GHz) on a gigabit network, it generates around 1Gb of data per hour, transferring several thousand messages per second (the exact number may vary according to message size, network bandwidth and broker setup).

Operating Systems:

  • Linux: x86 (experimental)and x86_64 (recommended)
  • OS X: x86

Broker Settings: ActiveMQ

ActiveMQ may need to have the inactivity monitor disabled. It can be done by adding the following setting in the conf/activemq.xml, in the transport connector setting:


For example:

<transportConnector name="amqp" uri="amqp://;wireFormat.maxFrameSize=104857600&amp;transport.useInactivityMonitor=false"/>

Usage - Performance Tool CLI

Here's an example of how to run a 10 minute and 30 seconds load test sending 256 bytes of data per message. Each command has to be run on a separate shell:

mpt-sender -d 10m30s -l debug -s 256 -b amqp://<hostname>/<queue name>
mpt-receiver -d 10m30s -l debug -s 256 -b amqp://<hostname>/<queue name>

Note: the CLI tool should be used for simple testing, smoke testing and other small scale verifications. It does not provide any mechanism for test orchestration or management.

Usage - Performance Tool Maestro

Maestro is a distributed test orchestration API that can be used to orchestrate the test orchestration between multiple test nodes. The tests are run by the maestro daemons and the test orchestration can be done either via the maestro CLI or via a Java and Groovy-based test orchestration api.

Maestro Broker

The maestro broker can be any MQTT-capable message broker. The daemons subscribe to different topics and, thus, receive the test instructions via the maestro API.


Maestro Overview

The protocol is documented in details here

Daemons Configuration

The daemons configuration is straight forward. Just edit the appropriate daemon file:

  • Sender daemon: /etc/sysconfig/mpt-sender-daemon
  • Receiver daemon: /etc/sysconfig/mpt-receiver-daemon
  • Inspector daemon: /etc/sysconfig/mpt-broker-inspector
  • Data server daemon: /etc/sysconfig/mpt-data-server

The configurations to be adjusted are the URL of the maestro broker and the unique NODE_NAME that identifies the node on the test cluster. The NODE_NAME must be in the format: name@hostname.


Additionally, other settings might be adjusted, although the defaults should be just fine. After configured, the daemons can be started using the the following command line:

systemctl start mpt-sender-daemon

Note: replace mpt-sender-daemon with mpt-receiver-daemon, mpt-broker-inspector or mpt-data-server.

Maestro CLI

The maestro CLI is a very simple command line interface that allows sending maestro commands to the maestro broker. To run the CLI, execute:

mpt-maestro -m mqtt://localhost:1883

On the CLI, several commands can be sent:


CLI Usage Examples:

Note: the purpose of the CLI is to serve as a way to run ad-hoc commands on the test cluster. For test orchestration, the Java or the Groovy API must be used.

Usage - Runtime Parameters and Message Customization

It is possible to customize protocol-specific parameters so that the tests closely match real world conditions. These parameters are usually configured by adjusting the broker URL. For example: amqp://host/queue?opt=value.

The following parameters can be set for AMQP:

Parameter Name Default Value Description
content-type text/plain Message content type
application-properties null Whether to skip instance creation process
ttl 5000 Time to live.
durable true Durable flag for the message
priority null Message priority (use 'variable' for random)
qos-mode at-most-once, at-least-once, exactly-once Default QOS mode

The following parameters can be set for MQTT:

Parameter Name Default Value Description
keep-alive text/plain Keep-alive interval
clean-session null MQTT clean session flag
retained null MQTT retained flag
qos-mode at-most-once, at-least-once, exactly-once Default QOS mode

Note: STOMP does not yet support parameters.

Note: always check the protocol specification for the exact meaning of the semantics of the flags.

Performance Tunning

Running with a large number of parallel connections require some tunning. In particular, the maximum unique queue size must be set to a larger value. On Linux, the default value is 16384. Ideally it should be increased to 65534. To do so run:

sysctl -w kernel.msgmnb=65536

This parameter can be made permanent by editing the file /etc/sysctl.conf.


  • Run the clients and the broker in different servers
  • Make sure that the time is properly set on both servers
  • Run on an dedicated network (or, at least, avoid hours of peak usage)
  • Measure the network performance before running (ie.: use iperf)
  • Ideally, you should run at a fixed rate instead of flooding the brokers. Brokers tend to get slower as the queue size increase.


The code is licensed under Apache License v2

You can’t perform that action at this time.