MQTT-Nachrichten pro Sekunde: Durchsatz abschätzen und messen

Die Abschätzung der MQTT-Nachrichten pro Sekunde ist die nützlichste Dimensionierungsübung, die Sie vor der Wahl eines Broker-Plans durchführen können, und sie dauert weniger als eine Stunde. Dieser Leitfaden zeigt Ihnen, wie Sie eingehende und ausgehende Nachrichtenraten für Ihre Flotte berechnen, Spitzen und Protokoll-Overhead berücksichtigen, realen Traffic mit einem kurzen Skript messen und die Zahlen in eine Planentscheidung übersetzen.

Eingehend, ausgehend und warum beides zählt

Ein Broker verarbeitet zwei Nachrichtenströme:

• Eingehend: Nachrichten, die Clients an den Broker publizieren.
• Ausgehend: Kopien, die der Broker an passende Subscriber zustellt.

Hat jede Nachricht genau einen Subscriber, sind beide gleich. In realen Systemen ist das selten der Fall. Eine Telemetrienachricht, die ein Dashboard, ein Historian und ein Alarmdienst lesen, erzeugt drei ausgehende Zustellungen. Ein Befehl an ein Gerät erzeugt eine. Ein Wildcard-Subscriber wie ein Debugging-Werkzeug auf # erhält alles. Der ausgehende Wert ist oft der größere, schätzen Sie daher immer beide ab.

Die Kernformeln

Sie brauchen nur drei:

1. Eingangsrate (Nachr./s) = Anzahl der Publisher x Nachrichten pro Publisher und Sekunde
2. Ausgangsrate (Nachr./s) = Eingangsrate auf jedem Topic x Anzahl passender Subscriber, summiert über alle Topics
3. Bandbreite (Bytes/s) = (Eingang + Ausgang) x durchschnittliche Nachrichtengröße, plus Protokoll- und TLS-Overhead

Nachrichtengröße bedeutet hier den MQTT-Payload plus den Topic-String und einige Bytes Fixed Header. Bei kleiner Telemetrie kann das Topic so groß sein wie der Payload, was ein Grund für die Topic-Aliase in MQTT 5 ist.

Denken Sie an QoS, wenn Sie in Paketen statt in Nachrichten rechnen. QoS 0 sendet ein Paket pro Zustellung. QoS 1 ergänzt für jeden Publish in jede Richtung ein PUBACK. QoS 2 nutzt einen Austausch aus vier Paketen. Die Anzahl der Nachrichten ändert sich nicht, wohl aber die Paketanzahl und die Arbeit des Brokers.

Ein Rechenbeispiel

Betrachten Sie eine hypothetische Anlage mit drei Arten von Publishern. Diese Zahlen dienen der Veranschaulichung und sind keine Messwerte.

Aus einer solchen Tabelle ergeben sich fast jedes Mal drei Beobachtungen:

• Fünfzehn schnelle Gateways erzeugen den Großteil des Traffics, während 120 langsame Sensoren kaum ins Gewicht fallen.
• Der Ausgang ist wegen des Fan-outs fast dreimal so hoch wie der Eingang.
• Die Verbindungszahl, 270 Clients plus die Backend-Subscriber, ist womöglich das Limit, an das Sie zuerst stoßen, lange bevor die Nachrichtenrate ein Thema wird.

In Industrie-4.0-Architekturen mit einem Unified Namespace (UNS) ist dieser Fan-out ausdrücklich gewollt: Maschinendaten werden einmal im UNS veröffentlicht, gegliedert nach der ISA-95-Hierarchie Enterprise, Site, Area, Line und Cell, und MES, Historian, OEE-Dashboard und Energiemonitoring abonnieren jeweils die Teilbäume, die sie brauchen. Jeder zusätzliche Konsument im Werk erhöht die Ausgangsrate, nicht die Eingangsrate. Planen Sie daher bei jedem neuen Anwendungsfall die zusätzlichen Subscriber mit ein.

Für Spitzen planen, nicht für Durchschnittswerte

Durchschnittswerte verbergen die Momente, die Ärger machen. Planen Sie ausdrücklich Reserven ein für:

• Reconnect-Fluten. Nach einem Ausfall verbinden sich Geräte gemeinsam neu, und viele senden gleichzeitig gepufferte Messwerte nach.
• Synchronisierte Timer. Geräte, die gleichzeitig booten und alle 60 Sekunden publizieren, publizieren in derselben Sekunde. Versehen Sie den ersten Publish mit zufälligem Jitter.
• Ereignisschübe. Alarme kaskadieren oft: Ein Fehler löst Dutzende zusammenhängender Alarme aus.
• Schicht- oder Zeitplanwechsel. Produktionslinien, die gemeinsam starten, erzeugen sprunghafte Traffic-Änderungen.
• Debug-Sitzungen. Wer in einem Desktop-Werkzeug # abonniert, fügt eine vollständige Kopie des gesamten Traffics hinzu.

Eine einfache Faustregel lautet, für eine Spitze von einem Mehrfachen des Durchschnitts zu dimensionieren und zu prüfen, dass Clients ihre Lastschübe mit Ratenbegrenzung und Jitter glätten.

Reale Nachrichtenraten messen

Schätzungen sind ein Ausgangspunkt; Messungen halten Sie ehrlich. Das folgende Skript abonniert einen Topic-Filter und gibt alle fünf Sekunden Nachrichten pro Sekunde und Bytes pro Sekunde aus. Richten Sie es mit Produktionszugangsdaten auf Ihren eigenen Broker aus, oder probieren Sie es auf dem öffentlichen MQTT-Broker mit einem eindeutigen Topic-Präfix. Dieser ist für Tests und Prototypen gedacht, nicht für Produktionsdaten.

# rate_meter.py - MQTT-Nachrichten pro Sekunde auf einem Topic-Filter messen
import sys
import threading
import time

import paho.mqtt.client as mqtt

HOST = "broker.connectmq.com"
FILTER = sys.argv[1] if len(sys.argv) > 1 else "connectmq/demo/r8m2/#"
WINDOW = 5

lock = threading.Lock()
count = 0
nbytes = 0
per_topic = {}

def on_connect(client, userdata, flags, reason_code, properties):
    print("connected:", reason_code, "- measuring", FILTER)
    client.subscribe(FILTER, qos=0)

def on_message(client, userdata, msg):
    global count, nbytes
    with lock:
        count += 1
        nbytes += len(msg.payload) + len(msg.topic)
        per_topic[msg.topic] = per_topic.get(msg.topic, 0) + 1

client = mqtt.Client(mqtt.CallbackAPIVersion.VERSION2,
                     client_id="rate-meter-r8m2", protocol=mqtt.MQTTv5)
# Für Ihren privaten Broker diese Zeilen einkommentieren und Port 8883 verwenden:
# client.username_pw_set("YOUR_USERNAME", "YOUR_PASSWORD")
# client.tls_set()
client.on_connect = on_connect
client.on_message = on_message
client.connect(HOST, 1883)
client.loop_start()

while True:
    time.sleep(WINDOW)
    with lock:
        msgs, size, top = count, nbytes, sorted(per_topic.items(), key=lambda kv: -kv[1])[:3]
        count = nbytes = 0
        per_topic.clear()
    print(f"{msgs / WINDOW:8.1f} msg/s  {size / WINDOW / 1024:8.2f} KB/s  top: {top}")

So erzeugen Sie in einem anderen Terminal Test-Traffic:

for i in $(seq 1 200); do
  mosquitto_pub -h broker.connectmq.com -p 1883 -i rate-pub-r8m2 \
    -t "connectmq/demo/r8m2/sensor/$((i % 5))" -m "{\"v\":$i}"
  sleep 0.2
done

Die Taktung ist wichtig: Der öffentliche MQTT-Broker erlaubt 10 Nachrichten pro Sekunde und Client, halten Sie Test-Publisher also darunter. Wenn Sie einen Produktions-Broker messen, betreiben Sie den Messclient als separaten Client mit eigenen Zugangsdaten und messen Sie in einer geschäftigen Phase, nicht über Nacht.

Durchsatz einem Broker-Plan zuordnen

Sobald Sie Zahlen haben, ordnen Sie sie den Planlimits zu. Bei ConnectMQ sind dies die Limits, die Sie prüfen müssen:

So lesen Sie die Tabelle im Abgleich mit Ihrer Schätzung:

1. Zuerst die Verbindungen. Addieren Sie Publisher, Subscriber, Dashboards und Werkzeuge. Diese Zahl entscheidet meist zwischen Serverless Free und Paid.
2. Als Zweites die größte Nachricht. Überschreitet irgendeine Nachricht, auch ein Rückstau-Batch, 256 KB, brauchen Sie den kostenpflichtigen Plan oder kleinere Batches.
3. Als Drittes QoS. Wenn ein Datenfluss Exactly-once-Zustellung erfordert, brauchen Sie QoS 2.
4. Als Viertes die Consumer-Skalierung. Wenn ein einzelner Backend-Subscriber mit Ihrer Ausgangsrate nicht Schritt hält, brauchen Sie Shared Subscriptions, um die Last auf mehrere Instanzen zu verteilen.
5. Zuletzt die Isolation. Wenn Ihr Durchsatz hoch und dauerhaft ist oder Sie nicht akzeptieren können, dass die Aktivität anderer Mandanten Ihre beeinflusst, besprechen Sie Dedicated oder BYOC und teilen Sie dem Team Ihre Eingangs-, Ausgangs- und Spitzenwerte mit.

Zum Verhalten beim Erreichen von Limits lesen Sie Verbindungslimits von MQTT-Brokern. Für das Gesamtbild beim Ausbau einer Bereitstellung siehe MQTT-Broker skalieren und wie viele Verbindungen ein MQTT-Broker schafft.

Möglichkeiten, die Nachrichtenrate zu senken

Wenn Ihre Schätzung höher ausfällt als gewünscht, reduzieren diese Techniken den Traffic, ohne Informationen zu verlieren:

• Report-by-Exception. Publizieren Sie, wenn sich ein Wert über ein Totband hinaus ändert, statt nach festem Timer. Sparkplug B baut auf genau diesem Prinzip auf.
• Messwerte bündeln. Senden Sie eine Nachricht mit zehn Messwerten statt zehn Nachrichten.
• Am Edge herunterrechnen. Publizieren Sie Sekundenmittelwerte statt roher hochfrequenter Messwerte, wenn die Consumer die Rohdaten nicht brauchen.
• Subscriptions eingrenzen. Entfernen Sie unnötige #-Subscriber, die den ausgehenden Traffic vervielfachen.
• Kompakte Payloads verwenden. Kürzere JSON-Schlüssel oder binäre Kodierungen wie Protobuf verringern die Bytes pro Nachricht.
• Topic-Aliase nutzen. Unter MQTT 5 verkürzen Aliase wiederholte lange Topic-Strings auf eine kleine Ganzzahl.

Starten Sie mit ConnectMQ

ConnectMQ ist ein verwalteter MQTT-Broker mit klaren Limits pro Plan, einem Live-Topic-Explorer und einem Dashboard, auf dem Sie den Traffic in Echtzeit verfolgen. Erstellen Sie unter app.connectmq.com einen kostenlosen Serverless-Broker, ohne Kreditkarte, lassen Sie den Ratenmesser dagegen laufen und wählen Sie den Plan, auf den Ihre Zahlen hinweisen. Die ganze Bandbreite an Hosting-Optionen finden Sie im Leitfaden zum Cloud-MQTT-Broker.

Häufig gestellte Fragen

Wie berechne ich MQTT-Nachrichten pro Sekunde?

Multiplizieren Sie die Anzahl der Publisher mit ihrer Publish-Häufigkeit, um die Eingangsrate zu erhalten, und multiplizieren Sie dann die Eingangsrate jedes Topics mit der Anzahl seiner Subscriber, um die Ausgangsrate zu erhalten. Planen Sie eine Reserve für Spitzen ein.

Warum ist der ausgehende Traffic höher als der eingehende?

Jede publizierte Nachricht wird an jeden passenden Subscriber zugestellt, sodass eine von drei Diensten gelesene Nachricht ausgehend dreifach zählt. Wildcard-Subscriber erhöhen das zusätzlich.

Beeinflusst QoS die Nachrichten pro Sekunde?

QoS ändert nicht, wie viele Nachrichten Sie senden, doch QoS 1 und 2 fügen jeder Nachricht Bestätigungspakete und Broker-Arbeit hinzu. Verwenden Sie QoS 0 für Telemetrie mit hoher Rate, bei der der nächste Messwert den letzten ersetzt.

Welche Nachrichtenrate erlaubt der öffentliche MQTT-Broker von ConnectMQ?

Der öffentliche MQTT-Broker erlaubt 10 Nachrichten pro Sekunde und Client, mit bis zu 64 KB pro Nachricht. Private Pläne sind über Verbindungszahl, Nachrichtengröße und QoS-Limits definiert, gleichen Sie diese also mit Ihrer Schätzung ab.