Die MQTT-Broker-Latenz nach Region ist wichtig, weil die physische Entfernung zwischen Ihren Geräten und dem Broker eine Untergrenze setzt, die sich durch kein Tuning beseitigen lässt. Dieser Leitfaden erklärt, woher MQTT-Latenz kommt, zeigt Ihnen, wie Sie Round-Trip-Zeiten von Ihren eigenen Standorten aus mit einem kurzen Skript messen, und liefert eine praktische Methode, um zu entscheiden, wo Ihr Broker laufen sollte.
Woher MQTT-Latenz kommt
Die Ende-zu-Ende-Latenz einer MQTT-Nachricht, vom publizierenden Sensor bis zum empfangenden Subscriber, setzt sich aus mehreren Teilen zusammen:
| Komponente | Was sie ist | Beeinflusst durch |
|---|---|---|
| Zugangsnetz | Gerät ins Internet: WLAN, Ethernet, Mobilfunk, Satellit | Funkbedingungen, Netzbetreiber, Gateway-Hardware |
| Signallaufzeit | Licht, das durch Glasfaser zum Broker und zurück läuft | Physische Entfernung und Routing-Pfad |
| Routing und Peering | Hops zwischen Netzwerken | Verbindungen zwischen ISPs und Cloud-Anbietern |
| Broker-Verarbeitung | Parsen, Autorisierung, Subscription-Abgleich, Zustellung | Broker-Last, Plan, Fan-out |
| Subscriber-Pfad | Broker zur konsumierenden Anwendung | Wo der Subscriber läuft |
| Client-Verhalten | Pufferung, Bündelung, QoS-Bestätigungen | Bibliothekseinstellungen und Ihr Code |
Die Wahl der Region beeinflusst vor allem Signallaufzeit und Routing. Licht bewegt sich in Glasfaser mit etwa zwei Dritteln seiner Vakuumgeschwindigkeit, was ungefähr 1 Millisekunde Round-Trip-Zeit pro 100 Kilometer Glasfaserstrecke ergibt, noch vor Umwegen im Routing. Reale Netzwerkpfade verlaufen selten geradlinig, daher sind gemessene Zeiten höher. Ein Gerät auf einem Kontinent, das mit einem Broker auf einem anderen kommuniziert, bezahlt diese Entfernung bei jedem Round Trip.
Der Verbindungsaufbau vervielfacht die Round Trips
Latenz schmerzt am meisten beim Verbindungsaufbau. Bevor die erste Nachricht fließt, braucht ein TLS-geschützter MQTT-Client einen TCP-Handshake, einen TLS-Handshake und einen MQTT-Austausch CONNECT/CONNACK. TLS 1.3 benötigt für seinen Handshake einen Round Trip, TLS 1.2 typischerweise zwei. Das bedeutet mehrere Round Trips vor dem ersten Publish, was bei Geräten auffällt, die aus dem Tiefschlaf erwachen, sich verbinden, publizieren und wieder trennen. Bei dauerhaft verbundenen Geräten fallen die Aufbaukosten einmal an, und die Round-Trip-Zeit im Normalbetrieb zählt mehr.
QoS fügt Round Trips für Bestätigungen hinzu
Ein QoS-0-Publish ist Fire-and-forget. QoS 1 wartet auf ein PUBACK, und QoS 2 braucht einen Austausch in vier Schritten. Die Nachricht erreicht die Subscriber etwa zur selben Zeit, doch der Publisher wartet länger, was bei Clients mit begrenztem In-flight-Fenster zählt. Unser Artikel zu MQTT-QoS-Leveln behandelt die Abwägungen.
So messen Sie die MQTT-Latenz von Ihren Standorten aus
Allgemeine Latenzkarten sind ein nützlicher Ausgangspunkt, doch was zählt, sind Ihre eigenen Messungen von Ihren eigenen Standorten. Messen Sie auf drei Ebenen.
Ebene 1: Netzwerk-Round-Trip-Zeit
Führen Sie auf einer Maschine am Gerätestandort Folgendes aus:
# ICMP-Round-Trip (wird in manchen Netzwerken blockiert)
ping -c 20 broker.connectmq.com
# Ansicht des Pfads pro Hop, nützlich zum Erkennen von Umwegen
mtr --report --report-cycles 20 broker.connectmq.com
# TCP-Verbindungszeit zum MQTT-TLS-Port
time nc -z -w 5 broker.connectmq.com 8883
Die nc-Zeile misst nur einen reinen TCP-Verbindungsaufbau; das MQTT-Skript unten liefert die nützlicheren Werte für TLS und Protokoll.
Ebene 2: MQTT-Verbindungsaufbau und Publish-Round-Trip
Dieses Python-Skript mit paho-mqtt 2.x misst die Zeit bis zum CONNACK über TLS und anschließend den Round Trip von Nachrichten, die derselbe Client publiziert und empfängt. Führen Sie es an jedem Standort aus, der Ihnen wichtig ist.
# mqtt_rtt.py - MQTT-Verbindungszeit und Publish/Receive-Round-Trip messen
import statistics
import sys
import threading
import time
import uuid
import paho.mqtt.client as mqtt
HOST = sys.argv[1] if len(sys.argv) > 1 else "broker.connectmq.com"
PORT = 8883
SAMPLES = 30
run_id = uuid.uuid4().hex[:8]
TOPIC = f"connectmq/demo/{run_id}/rtt"
connected = threading.Event()
received = threading.Event()
rtts = []
sent_at = 0.0
def on_connect(client, userdata, flags, reason_code, properties):
client.subscribe(TOPIC, qos=0)
def on_subscribe(client, userdata, mid, reason_codes, properties):
connected.set()
def on_message(client, userdata, msg):
rtts.append((time.perf_counter() - sent_at) * 1000)
received.set()
client = mqtt.Client(mqtt.CallbackAPIVersion.VERSION2,
client_id=f"rtt-{run_id}", protocol=mqtt.MQTTv5)
# Für einen privaten Broker Zugangsdaten ergänzen:
# client.username_pw_set("YOUR_USERNAME", "YOUR_PASSWORD")
client.tls_set()
client.on_connect = on_connect
client.on_subscribe = on_subscribe
client.on_message = on_message
t0 = time.perf_counter()
client.connect(HOST, PORT, keepalive=30)
client.loop_start()
if not connected.wait(15):
sys.exit("could not connect and subscribe")
print(f"connect + TLS + subscribe: {(time.perf_counter() - t0) * 1000:.0f} ms")
for i in range(SAMPLES):
received.clear()
sent_at = time.perf_counter()
client.publish(TOPIC, str(i), qos=0)
if not received.wait(5):
print("timeout on sample", i)
time.sleep(0.2) # auf dem öffentlichen Broker deutlich unter 10 Nachr./s bleiben
client.loop_stop()
client.disconnect()
if rtts:
rtts.sort()
print(f"publish->receive RTT over {len(rtts)} samples: "
f"median {statistics.median(rtts):.1f} ms, "
f"p90 {rtts[int(len(rtts) * 0.9) - 1]:.1f} ms, max {rtts[-1]:.1f} ms")
Da derselbe Client publiziert und empfängt, ist das Ergebnis ein vollständiger Round Trip durch den Broker, was ein guter Näherungswert für die Latenz vom Gerät zum Backend ist, wenn Ihr Backend nahe am Broker liegt. Das Skript nutzt den Öffentlichen MQTT-Broker mit einem zufälligen Topic und läuft daher ohne Konto; für Messungen mit echten Produktionsdaten verwenden Sie einen privaten Broker.
Ebene 3: Regionen, die Sie selbst kontrollieren
Um Standorte vor einer Festlegung zu vergleichen, starten Sie in jeder infrage kommenden Cloud-Region eine kleine virtuelle Maschine, installieren Mosquitto mit TLS und führen von jedem Standort aus dasselbe Skript gegen jede davon aus. So erhalten Sie eine Matrix realer Zahlen statt Annahmen.
Aus Messungen eine Entscheidung ableiten
Sammeln Sie die Ergebnisse in einer Tabelle wie dieser, mit Medianwerten und einem hohen Perzentil statt einzelner Pings:
| Standort | Region A Median / p90 | Region B Median / p90 | Region C Median / p90 | Geräteanzahl |
|---|---|---|---|---|
| Werk Stuttgart | ... | ... | ... | ... |
| Werk Linz | ... | ... | ... | ... |
| Lager Basel | ... | ... | ... | ... |
| Backend-Dienste | ... | ... | ... | n/a |
Wenden Sie dann diese Regeln an:
- Nach Bedeutung gewichten, nicht nur nach Geräteanzahl. Ein Regelkreis an einem Standort kann wichtiger sein als Hunderte Dashboards anderswo, und eine MES-Anbindung im Werk wiegt oft schwerer als ein Reporting in der Zentrale.
- Ihr Backend einbeziehen. Wenn Datenbanken und Dienste in einer Cloud-Region laufen, fügt ein weit entfernter Broker jeder konsumierten Nachricht Latenz hinzu.
- Auf p90 und Maximum schauen, nicht nur auf den Median. Jitter zählt bei allem Interaktiven.
- Anforderungen an die Datenresidenz prüfen. Datenschutzvorgaben wie die DSGVO oder Vorgaben Ihrer Kunden können die Region festlegen, bevor die Latenz es tut; siehe MQTT-Datenresidenz.
- Partitionierung erwägen. Wenn Standorte über Kontinente verteilt sind und niedrige Latenz brauchen, können separate Broker pro Region einen zentralen Broker übertreffen. In einem Unified Namespace (UNS) nach ISA-95 ist diese Aufteilung bereits angelegt: Jeder Site-Teilbaum, etwa
acme/werk-linz/..., kann auf einem Broker nahe am Werk liegen, während Enterprise, Area, Line und Cell als Topic-Struktur einheitlich bleiben. Details zum Konzept finden Sie unter Sparkplug B und Unified Namespace. - Latenz ist selten der einzige Faktor. Kosten, Datenresidenz und betriebliche Einfachheit wiegen bei Telemetrie, die von Menschen gelesen wird, oft schwerer als ein paar Millisekunden.
Einen Bereitstellungsort bei ConnectMQ wählen
ConnectMQ bietet mehrere Bereitstellungsmodelle, und der Standort funktioniert in jedem anders:
- Serverless (Free und Paid): Ihr Broker läuft auf dem geteilten Cluster von ConnectMQ. Führen Sie das Messskript von Ihren Standorten aus dagegen aus, um zu sehen, ob die Round-Trip-Zeit Ihren Anforderungen genügt.
- Dedicated: ein isolierter Cluster für Ihren Workload. Besprechen Sie die Standortoptionen mit dem Team und bringen Sie Ihre Messtabelle mit.
- BYOC: Der Broker läuft in Ihrem eigenen Cloud-Konto und kann daher in der Region stehen, in der Ihre anderen Systeme bereits laufen. Klären Sie bei der Planung die unterstützten Anbieter und Regionen mit dem Team; unser Leitfaden zum BYOC-MQTT-Broker beschreibt das Modell.
- Self Managed Enterprise: Sie platzieren ihn dort, wo Sie Ihre eigene Infrastruktur betreiben.
Für die meisten Telemetrie- und Monitoring-Workloads genügt ein gut platzierter Broker in derselben groben Region wie die Geräte. Enge Regelkreise, etwa zwischen SPS und Antrieb, halten Sie lokal am Edge und nutzen den Cloud-MQTT-Broker für Überwachung, Reporting und Integration. Unser Artikel zur Latenz von Echtzeit-Digital-Twins erläutert diese Aufteilung ausführlicher.
Häufige Latenzfallen
- Einmal aus dem Büro messen. Messen Sie aus den tatsächlichen Gerätenetzen, besonders an Mobilfunkstandorten.
- Dem Broker die Schuld am WLAN geben. Führen Sie zuerst die Netzwerktests aus; Zugangsnetze tragen oft mehr Verzögerung bei als die Entfernung.
- Für jede Nachricht neu verbinden. Geräte im Tiefschlaf zahlen pro Aufwachen mehrere Round Trips; halten Sie Sitzungen offen, wo die Energieversorgung es erlaubt.
- Subscriber weit vom Broker entfernt platzieren. Ein Backend in einer anderen Region verdoppelt die Strecke, die jede Nachricht zurücklegt.
- DNS ignorieren. Langsame Resolver verzögern jede neue Verbindung; cachen Sie Ergebnisse auf Gateways.
Messen Sie Ihre Latenz mit ConnectMQ
ConnectMQ ist ein verwalteter MQTT-Broker mit den Bereitstellungsoptionen Serverless, Dedicated und BYOC, sodass Sie den Standort auf Ihre Anlagen und Systeme abstimmen können. Erstellen Sie unter app.connectmq.com einen kostenlosen Serverless-Broker, ohne Kreditkarte, führen Sie das Skript von Ihren Standorten aus aus und nutzen Sie die Ergebnisse, um Ihr Produktions-Setup zu wählen. Der Leitfaden zum Cloud-MQTT-Broker behandelt den Rest der Hosting-Entscheidung, und MQTT-Broker skalieren die Kapazität.
Häufig gestellte Fragen
Wie stark beeinflusst die Wahl der Region die MQTT-Latenz?
Die Entfernung setzt eine minimale Round-Trip-Zeit von etwa 1 Millisekunde pro 100 Kilometer Glasfaser, und reale Routen fügen mehr hinzu. Bei Geräten auf einem anderen Kontinent dominiert die Wahl der Region meist den Netzwerkanteil der Latenz.
Wie misst man die Latenz eines MQTT-Brokers am besten?
Führen Sie vom Gerätestandort aus einen Test auf MQTT-Ebene durch, der Verbindungsaufbau, TLS und einen Round Trip von Publish bis Empfang misst, und erfassen Sie Medianwerte und hohe Perzentile über viele Stichproben.
Macht TLS MQTT langsamer?
TLS fügt beim Verbindungsaufbau Round Trips hinzu, kostet danach pro Nachricht aber sehr wenig. Halten Sie Verbindungen nach Möglichkeit offen, damit der Handshake nur einmal anfällt.
Kann ich wählen, wo mein ConnectMQ-Broker läuft?
Mit BYOC läuft der Broker in Ihrem eigenen Cloud-Konto, sodass Sie die Region innerhalb der vom Team unterstützten Optionen wählen. Bei Dedicated-Bereitstellungen besprechen Sie den Standort mit dem Team.
