Lasttest für MQTT-Broker: Durchsatz und Latenz messen

Ein Broker, der mit einem Testclient funktioniert, kann mit tausend Geräten trotzdem umfallen. Ein Lasttest für den MQTT-Broker beantwortet drei Fragen, bevor es die Produktion tut: wie viele gleichzeitige Verbindungen er annimmt, wie viele Nachrichten pro Sekunde er routen kann und welche Latenz deine Subscriber sehen, während er ausgelastet ist.

Diese Anleitung zeigt, wie du einen Benchmark planst, ihn mit zwei Open-Source-Tools und einem Python-Skript ausführst und die Zahlen liest, ohne dich selbst zu täuschen.

Was du messen solltest

Benchmarke immer mit demselben QoS, derselben Payload-Größe und derselben Topic-Struktur, die deine Geräte verwenden. Ein Test, der 10-Byte-Nachrichten mit QoS 0 auf ein einziges Topic schickt, sagt nichts über 2-KB-Telemetrie mit QoS 1 aus, die über 50.000 Topics verteilt ist. In MQTT-QoS-Stufen siehst du, wie jede Stufe die Paketanzahl verändert.

Das richtige Ziel wählen

Lass niemals einen schweren Benchmark gegen eine geteilte öffentliche Sandbox laufen – die Zahlen sind bedeutungslos (du konkurrierst mit allen anderen Nutzern), und die Betreiber werden dich drosseln oder sperren. Mach dort einen Smoke-Test und richte die Last dann auf eine Instanz, die du kontrollierst.

In den folgenden Beispielen verwenden wir broker.connectmq.com; ersetze Host, Port und Zugangsdaten durch die deiner eigenen Instanz.

1. emqtt-bench

emqtt-bench ist ein Erlang-Tool, das von einer einzigen Maschine aus Zehntausende Verbindungen öffnen kann. Am einfachsten startest du es mit Docker:

docker run --rm -it emqx/emqtt-bench conn \
  -h broker.connectmq.com -p 1883 \
  -c 2000 -R 200 \
  -u "$MQTT_USER" -P "$MQTT_PASS"

Miss dann den Durchsatz mit einer Gruppe von Subscribern und einer Gruppe von Publishern, die gleichzeitig laufen:

docker run --rm -it emqx/emqtt-bench sub \
  -h broker.connectmq.com -p 1883 \
  -c 100 -t 'bench/%i/#' -q 1

docker run --rm -it emqx/emqtt-bench pub \
  -h broker.connectmq.com -p 1883 \
  -c 100 -I 10 -t 'bench/%i/data' -s 256 -q 1

%i wird zum Client-Index expandiert, sodass jeder Publisher sein eigenes Topic und seinen eigenen Subscriber hat – ein realistisches 1:1-Telemetriemuster. 100 Publisher × 100 msg/s ergeben ein Ziel von 10.000 Nachrichten pro Sekunde. emqtt-bench gibt jede Sekunde die Sende- und Empfangsraten aus; fällt die Empfangsrate hinter die Senderate zurück, ist der Broker (oder dein Netzwerk) der Engpass.

2. mqtt-benchmark (Go)

Wenn du ein einzelnes Binary bevorzugst: mqtt-benchmark veröffentlicht eine feste Anzahl von Nachrichten und meldet Statistiken zu Durchsatz und Latenz:

go install github.com/krylovsk/mqtt-benchmark@latest

mqtt-benchmark \
  --broker tcp://broker.connectmq.com:1883 \
  --clients 50 --count 1000 --size 512 --qos 1 \
  --topic bench/go --format text

Die Zusammenfassung am Ende enthält Nachrichten pro Sekunde je Client, die Gesamtrate sowie Mittelwert und Standardabweichung der Publish-Zeiten – ein schneller Weg, zwei Broker oder zwei Konfigurationen zu vergleichen.

3. Ein Latenz-Skript, dem du vertrauen kannst

Durchsatz-Tools messen, wie schnell Nachrichten hineingehen. Nutzer spüren, wie schnell sie herauskommen. Dieses Python-Skript (paho-mqtt 2.x) bettet die Sendezeit in jede Payload ein und berechnet auf der Subscriber-Seite Ende-zu-Ende-Perzentile:

import json, statistics, time, uuid
import paho.mqtt.client as mqtt

HOST, PORT = "broker.connectmq.com", 1883
TOPIC = f"bench/{uuid.uuid4().hex[:8]}/latency"
N, RATE = 2000, 200          # Nachrichten, Nachrichten pro Sekunde
samples = []

def on_message(client, userdata, msg):
    sent = json.loads(msg.payload)["t"]
    samples.append((time.perf_counter() - sent) * 1000)

sub = mqtt.Client(mqtt.CallbackAPIVersion.VERSION2)
sub.on_message = on_message
sub.connect(HOST, PORT)
sub.subscribe(TOPIC, qos=1)
sub.loop_start()

pub = mqtt.Client(mqtt.CallbackAPIVersion.VERSION2)
pub.connect(HOST, PORT)
pub.loop_start()
time.sleep(1)                # Subscription kurz wirken lassen

for i in range(N):
    pub.publish(TOPIC, json.dumps({"i": i, "t": time.perf_counter()}), qos=1)
    time.sleep(1 / RATE)

time.sleep(3)
samples.sort()
p = lambda q: samples[int(len(samples) * q) - 1]
print(f"received {len(samples)}/{N}")
print(f"p50 {p(0.50):.1f} ms  p95 {p(0.95):.1f} ms  p99 {p(0.99):.1f} ms  max {samples[-1]:.1f} ms")
print(f"mean {statistics.mean(samples):.1f} ms")

Da Publisher und Subscriber im selben Prozess laufen, teilen sie sich eine Uhr – kein NTP-Drift im Ergebnis. Lass das Skript einmal im Leerlauf laufen und einmal, während emqtt-bench den Broker unter Feuer nimmt: Die Differenz ist die Latenz, die deine Geräte in der Spitze sehen werden.

Ergebnisse richtig lesen

• Empfangen < gesendet bei QoS 0 bedeutet, dass Broker oder Client unter Druck Nachrichten verworfen haben. Wiederhole den Test mit QoS 1, um zu sehen, ob es ein Zustellungs- oder ein Kapazitätsproblem ist.
• p99 weit über p50 deutet auf Garbage-Collection-Pausen, festplattenbasierte Persistenz oder eine ausgelastete Netzwerkverbindung hin. Prüfe die CPU des Brokers und die des Lastgenerators – eine voll ausgelastete Benchmark-Maschine ist das häufigste Fehlergebnis.
• Der Verbindungstest bleibt bei einer runden Zahl stehen (1.024, 4.096, 65.535) – du hast ein File-Descriptor- oder Ephemeral-Port-Limit auf dem Lastgenerator erreicht, nicht auf dem Broker. Erhöhe ulimit -n oder verteile die Last auf mehrere Maschinen oder Quell-IPs.
• Verbindungsabbrüche während des Laufs – achte auf Keep-Alive-Timeouts oder die Inflight-/Queue-Limits pro Client des Brokers. Siehe MQTT Keep Alive und Verbindungsfehler.

Eine wiederholbare Lasttest-Checkliste

1. Mach zuerst einen Smoke-Test der Konnektivität mit dem Online-MQTT-Client oder mit mosquitto_pub / mosquitto_sub.
2. Leg das Szenario fest: Anzahl der Clients, QoS, Payload-Größe, Topic-Layout, retained oder nicht.
3. Steigere die Last schrittweise (10 %, 50 %, 100 %, 150 % der erwarteten Spitze) und halte jede Stufe einige Minuten.
4. Zeichne CPU, Speicher und Verbindungsanzahl des Brokers neben den clientseitigen Zahlen auf.
5. Wiederhole den Lauf zweimal; vertraue nur Ergebnissen, die sich reproduzieren lassen.
6. Wiederhole den Test nach jedem Broker-Upgrade und jeder Konfigurationsänderung.

Zuerst einen Smoke-Test im Browser machen

Lasttests machen aus „funktioniert auf meinem Laptop" eine Zahl, mit der du Kapazität planen kannst. Fang klein an, miss die Latenz dort, wo deine Nutzer sind, und leg die Skripte in dein Repository, damit der nächste Benchmark Minuten statt Tage dauert.

Häufig gestellte Fragen