MQTT Performance
Diese Seite beschreibt die Leistungscharakteristik des MQTT-Plug-ins im OPC Router auf Basis realer Benchmark-Messungen (siehe Benchmark-Details).
Einflussfaktoren auf die Performance
Hauptfaktoren
- Round Trip Time (RTT) – Latenz zwischen OPC Router und Broker. Hat direkten Einfluss auf Durchsatz und Latenz, insbesondere bei QoS 1 und QoS 2.
- QoS-Level – Bestimmt die Anzahl der Bestätigungsschritte zwischen Client und Broker.
- Connection Pooling – Erhöht den Durchsatz bei parallelen Transfers.
- Brokerleistung – Interne Warteschlangen, Topic-Filter und CPU-/I/O-Last.
- Routerkonfiguration – Anzahl Transfers pro Sekunde, aktivierte Optionen (Deduplication, Wait-for-Transfer etc.).
Quality of Service (QoS)
| QoS | Beschreibung | Kommunikationsphasen | Typische RTT | Relative Geschwindigkeit | Typische lokale Latenz |
|---|---|---|---|---|---|
| 0 | Fire & forget – keine Bestätigung | 1 (Client → Broker) | 0,5 × RTT | 🟢 Sehr hoch | < 10 ms |
| 1 | Empfangsbestätigung (PUBACK) | 2 (Client ↔ Broker) | 1 × RTT | 🟡 Mittel | 20–80 ms |
| 2 | 4-Wege-Handshake (PUBREC/PUBREL/PUBCOMP) | 4 (Client ↔ Broker) | 2 × RTT | 🔴 Niedrig | 40–150 ms |
Network Round Trip Time (RTT)
Die RTT (Round Trip Time) ist die Zeit, die ein Datenpaket benötigt, um vom OPC Router zum MQTT-Broker und wieder zurück zu gelangen. Sie hängt stark von der Netzwerkumgebung ab und beeinflusst direkt die Performance der MQTT-Kommunikation.
| Umgebung | Typische RTT | Beschreibung |
|---|---|---|
| Lokal (gleicher Host) | 0,5–2 ms | Lokaler Mosquitto-Broker oder Docker-Container auf derselben Maschine |
| Lokales Netzwerk (LAN) | 1–5 ms | Broker im gleichen Netzsegment oder Rechenzentrum |
| Unternehmensnetz (Corp-VPN) | 10–40 ms | VPN- oder MPLS-basierte Standortverbindung, zusätzliche Verschlüsselungslatenz |
| Cloud (Hyperscaler) | 30–100 ms | MQTT Broker in Azure, AWS oder Google Cloud, abhängig von Region und Peering |
| Weitverkehrsnetz (WAN) | 80–250 ms | Internationale oder mobile Verbindungen, ggf. über öffentliche Netze |
Bei QoS 1 oder QoS 2 verlängert sich die effektive Übertragungszeit linear mit der RTT, da jede Bestätigungsrunde eine vollständige Hin- und Rücklaufzeit benötigt.
Connection Pooling
Das Connection Pooling verteilt Publish-Vorgänge auf mehrere parallele MQTT-Verbindungen und erhöht so die Durchsatzrate erheblich.
| Parameter | Beschreibung |
|---|---|
| Min. connections | Mindestanzahl gleichzeitig offener Verbindungen |
| Max. connections | Obergrenze für parallele MQTT-Verbindungen (einstellbar bis 100) |
| Idle timeout | Zeit bis zum Schließen inaktiver Verbindungen |
Vorteile
- Deutlich höherer Durchsatz bei vielen Transfers
- Lastverteilung auf mehrere Threads
- Vermeidung von Blockaden bei QoS 1/2
Empfehlung
| Szenario | Empfohlene Einstellung |
|---|---|
| Wenige Transfers / einfache Telemetrie | Pool deaktivieren (Single Connection) |
| Mittlere bis hohe Last | Min. = 5, Max. = 50 |
| Sehr hohe Last oder parallele Topics | Min. = 10, Max. = 100 |
Reale Benchmark-Ergebnisse (lokal)
Gemessen mit Mosquitto 2.0.22, OPC Router 5.5, Windows Sandbox (i7-13700, 4 GB RAM), 100 Byte Payload.
Siehe MQTT Benchmark Ergebnisse
| transfer flows | QoS | Avg. Throughput [msg/s] | Max. [msg/s] | Kommentar |
|---|---|---|---|---|
| 1 | 0 | 64 | 65 | Basislast ohne Pool |
| 1 | 1 | 63 | 65 | Kaum Unterschied zu QoS 0 (lokal) |
| 10 | 0 | 640 | 650 | Lineare Skalierung mit Anzahl Connections |
| 10 | 1 | 616 | 648 | Leichter Overhead durch PUBACK |
| 50 | 0 | 2670 | 3117 | Starke Parallelisierung, leichte Schwankungen |
| 100 | 0 | 4230 | 5286 | Maximale getestete Rate ohne Pool |
| 50 (Pool) | 0 | 3025 | 3230 | +13 % Steigerung durch Pooling |
| 100 (Pool) | 0 | 5556 | 6118 | Höchster gemessener Durchsatz |
Alle Werte stammen aus lokalen Benchmarks (RTT ≈ 1 ms). In realen Netzwerken reduziert sich der Durchsatz proportional zur RTT, da jede QoS-Bestätigung zusätzliche Laufzeit erfordert.
Optimierungsempfehlungen
- QoS 0 für schnelle, nicht-kritische Daten (z. B. Telemetrie, Messwerte)
- QoS 1 als Standard für Zustellsicherheit mit akzeptabler Performance
- QoS 2 nur bei absolut notwendiger Genauigkeit
- Connection Pooling aktivieren bei hoher Parallelität oder MQTT 5 Batch-Transfers
- Deduplication deaktivieren, wenn Daten häufig gleich bleiben
- Cycle Time (Experten-Einstellung) nur reduzieren, wenn CPU-Last stabil bleibt
- Keep Alive / Timeout-Werte an RTT des Netzwerks anpassen