Wie viele Verbindungen schafft ein MQTT-Broker?

Wie viele Verbindungen schafft ein MQTT-Broker? Die ehrliche Antwort lautet „Es kommt darauf an“, allerdings auf eine kurze, konkrete Liste von Ressourcen, die Sie messen und einplanen können. Dieser Artikel erklärt, was gleichzeitige MQTT-Verbindungen begrenzt, warum veröffentlichte Zahlen selten zu Ihrem Workload passen, wie Sie die Kapazität selbst testen und wie Anbieter verwalteter MQTT-Broker all das in Planlimits übersetzen.

Warum es keine einzelne Zahl gibt

In Herstellermarketing und Konferenzvorträgen finden Sie beeindruckende Verbindungszahlen. Sie sind meist real, aber unter bestimmten Bedingungen gemessen: inaktive Clients, kein TLS oder mit Session Resumption, winzige oder gar keine Payloads, großzügige Hardware und sorgfältig getunte Kernel. Ändern Sie eine dieser Bedingungen, verschiebt sich die Zahl.

Für Sie zählt nicht das Maximum, das ein Broker im Labor erreicht, sondern wie viele Ihrer Clients mit Ihren Keepalive-, TLS-, Subscription- und Nachrichtenmustern eine bestimmte Bereitstellung mit Reserve bedienen kann. Dazu muss man die Engpässe verstehen.

Was gleichzeitige MQTT-Verbindungen begrenzt

Arbeitsspeicher

Bei großen Flotten ruhiger Geräte ist der Arbeitsspeicher meist die erste harte Grenze. Jede Verbindung bringt Kernel-Socket-Puffer, die eigenen Strukturen des Brokers pro Client, TLS-Sitzungszustand und gepufferte Nachrichten mit sich. Subscriptions kommen hinzu, besonders bei vielen Wildcard-Filtern. Clients, die sich mit persistenten Sitzungen trennen, belegen weiter Speicher, bis die Sitzung abläuft.

Dateideskriptoren

Unter Linux verbraucht jeder Socket einen Dateideskriptor. Das Standard-Softlimit vieler Distributionen ist für einen Broker viel zu niedrig, weshalb „too many open files“ einer der häufigsten Fehler beim ersten Selbsthosting ist. Sie können es prüfen und erhöhen:

# Aktuelle Limits der Shell
ulimit -n
ulimit -Hn

# Limits eines laufenden Broker-Prozesses (PID ersetzen)
cat /proc/PID/limits | grep "open files"

# Offene Sockets des Brokers zählen
ls /proc/PID/fd | wc -l

Bei einem systemd-Dienst erhöhen Sie das Limit in einer Drop-in-Datei:

# /etc/systemd/system/mosquitto.service.d/limits.conf
[Service]
LimitNOFILE=200000

Führen Sie dann sudo systemctl daemon-reload && sudo systemctl restart mosquitto aus.

TLS

TLS schützt jede produktive Verbindung, und das hat seinen Preis. Die laufende Verschlüsselung kleiner MQTT-Nachrichten ist günstig, der Handshake dagegen vergleichsweise teuer. Das zählt vor allem, wenn sich viele Clients gleichzeitig verbinden, etwa nach einem standortweiten Stromausfall oder einem Broker-Neustart. Ein Broker, der seine Flotte im Normalbetrieb bequem hält, kann trotzdem Mühe haben, alle Clients in derselben Minute anzunehmen. Reconnect-Verzögerungen mit Jitter auf den Clients sind die beste Abwehr.

Keepalives

Jeder Client sendet ein PINGREQ, wenn er innerhalb seines Keepalive-Intervalls nichts anderes zu senden hat. Über eine große Flotte erzeugen sehr kurze Keepalives eine ständige Grundlast. Ein Keepalive von etwa 30 bis 60 Sekunden ist ein gängiger Kompromiss zwischen schneller Fehlererkennung und Overhead; batteriebetriebene Geräte nutzen oft längere Werte.

Netzwerkpfad

Load Balancer, NAT-Gateways und Firewalls halten alle einen Zustand pro Verbindung und haben eigene Limits. Prüfen Sie in selbst gehosteten Umgebungen den Accept-Backlog des Kernels (net.core.somaxconn) und die Größe der Connection-Tracking-Tabellen, wenn Sie eine zustandsbehaftete Firewall vor den Broker setzen.

So testen Sie die Verbindungskapazität selbst

Wenn Sie Ihren eigenen Broker betreiben, messen Sie, statt zu raten. Das folgende Skript öffnet von einer Maschine aus viele inaktive Verbindungen zu einem Broker, den Sie selbst kontrollieren, etwa einer lokalen Mosquitto-Instanz. Führen Sie Verbindungstests nie gegen einen geteilten oder öffentlichen Broker aus; Sie lösen damit den Flood-Schutz aus und beeinträchtigen andere Nutzer.

# conn_test.py - N inaktive MQTT-Verbindungen zu IHREM EIGENEN Broker (nur zum Testen) öffnen
import sys
import time
import paho.mqtt.client as mqtt

HOST = sys.argv[1] if len(sys.argv) > 1 else "localhost"
COUNT = int(sys.argv[2]) if len(sys.argv) > 2 else 500

connected = 0

def on_connect(client, userdata, flags, reason_code, properties):
    global connected
    if not reason_code.is_failure:
        connected += 1

clients = []
start = time.time()
for i in range(COUNT):
    c = mqtt.Client(mqtt.CallbackAPIVersion.VERSION2, client_id=f"conn-test-{i}")
    c.on_connect = on_connect
    try:
        c.connect(HOST, 1883, keepalive=60)
        c.loop_start()
        clients.append(c)
    except OSError as exc:
        print(f"failed at {i}: {exc}")
        break
    if i % 100 == 0:
        time.sleep(0.5)        # Hochlauf drosseln

time.sleep(5)
print(f"{connected}/{COUNT} connected in {time.time() - start:.1f}s")
input("Press Enter to disconnect all clients...")
for c in clients:
    c.disconnect()
    c.loop_stop()

Führen Sie es mit python conn_test.py localhost 2000 aus und beobachten Sie dabei Speicher und CPU des Brokers mit top oder htop. Beachten Sie, dass jeder paho-Client einen eigenen Thread startet, sodass irgendwann die Testmaschine selbst zum Engpass wird; spezialisierte Lastwerkzeuge mit Event Loops skalieren weiter. Erhöhen Sie ulimit -n auch auf der Testmaschine. Wiederholen Sie den Test mit aktiviertem TLS und realistischen Subscriptions, denn Werte mit inaktiven Clients über reines TCP sind die optimistischsten, die Sie je sehen werden.

Wie verwaltete MQTT-Broker Verbindungslimits festlegen

Anbieter verwalteter MQTT-Broker unterliegen denselben Beschränkungen, verwandeln sie aber in Plankontingente, damit Sie keine Kernel tunen müssen. Auf einem geteilten Cluster schützt das Kontingent außerdem jeden Mandanten vor jedem anderen.

ConnectMQ veröffentlicht diese Verbindungslimits pro Plan:

Bei Dedicated und BYOC hängt die richtige Zahl von den Faktoren in diesem Artikel ab: Ihrem Keepalive, der TLS-Nutzung, der Nachrichtenrate und dem Sitzungsverhalten. Teilen Sie diese Details bei der Planung der Bereitstellung mit, statt nach einer einzelnen Schlagzeilenzahl zu fragen. Überschreiten Sie ein Kontingent, erhalten MQTT-5-Clients den Reason Code 0x97 Quota exceeded; unser Leitfaden zu Verbindungslimits von MQTT-Brokern erklärt, wie Sie damit umgehen.

Verbindungen richtig zählen

Teams zählen häufig zu wenig. Nutzen Sie bei der Schätzung diese Checkliste:

1. Jedes Gerät oder Gateway mit eigener MQTT-Sitzung.
2. Jede Instanz eines Backend-Dienstes: Datenbank-Writer, Alarmierung, APIs.
3. Jedes Integrationswerkzeug wie Node-RED, Telegraf oder Home Assistant.
4. Jedes Dashboard oder jeder Browser-Tab mit einem MQTT-Client über WebSocket.
5. Entwicklerwerkzeuge: Desktop-Explorer, CLI-Sitzungen, Testskripte.
6. Vorübergehende Überlappung bei Deployments, wenn alte und neue Dienstinstanzen gleichzeitig laufen.
7. Wachstumsreserve für die nächsten sechs bis zwölf Monate.

Gateways verändern die Rechnung. Ein Industrie-Gateway, das fünfzig SPS-Tags bündelt, oder ein BLE-Gateway, das Dutzende Sensoren weiterleitet, nutzt eine MQTT-Verbindung, nicht fünfzig. Wenn Sie nahe an einem Planlimit sind, ist das Bündeln am Edge oft günstiger als ein Upgrade. Das gilt besonders in Industrie-4.0-Projekten: Wenn Edge-Gateways pro Linie oder Zelle die Maschinendaten aus SPS und OPC-UA-Servern in einen Unified Namespace (UNS) publizieren, dessen Topics der ISA-95-Hierarchie folgen (etwa acme/werk-stuttgart/montage/linie-1/zelle-3/temperatur), wächst die Verbindungszahl mit den Gateways, nicht mit den Datenpunkten.

Praktische Erkenntnisse

• Die Verbindungskapazität ist eine Funktion aus Arbeitsspeicher, Dateideskriptoren, TLS-Kosten, Keepalive-Traffic und Sitzungszustand, keine feste Zahl.
• Kapazität im Normalbetrieb und Kapazität bei Reconnect-Stürmen sind verschieden; entwerfen Sie Clients mit Backoff und Jitter.
• Testen Sie Ihren eigenen Workload auf Hardware, die Sie kontrollieren, mit aktiviertem TLS.
• Bei einem verwalteten MQTT-Broker sind die Plankontingente die maßgebliche Zahl, und Sie sollten jeden Client zählen, nicht nur Geräte.

Zum Durchsatz statt zu Verbindungen lesen Sie MQTT-Nachrichten pro Sekunde abschätzen, und zu Wachstumsstrategien MQTT-Broker skalieren. Der Leitfaden zum Cloud-MQTT-Broker stellt alles in den Kontext der Hosting-Entscheidungen.

Starten Sie mit ConnectMQ

ConnectMQ ist ein verwalteter MQTT-Broker mit klaren Verbindungslimits pro Plan, sodass Sie Kapazität planen können, ohne Server zu tunen. Erstellen Sie unter app.connectmq.com einen kostenlosen Serverless-Broker, ohne Kreditkarte, und wechseln Sie mit wachsender Flotte zu Serverless (Paid), Dedicated oder BYOC.

Häufig gestellte Fragen

Wie viele Verbindungen schafft ein MQTT-Broker auf einem einzelnen Server?

Das hängt von Arbeitsspeicher, Limits für Dateideskriptoren, TLS-Nutzung, Keepalive-Intervallen und Sitzungszustand ab. Messen Sie mit Ihrem eigenen Client-Verhalten und aktiviertem TLS, statt sich auf eine Schlagzeilenzahl zu verlassen.

Verringert TLS die Anzahl der Verbindungen, die ein MQTT-Broker schafft?

TLS erhöht den Speicherbedarf pro Verbindung und macht Handshakes CPU-intensiv, was vor allem bei Reconnect-Stürmen ins Gewicht fällt. Verschlüsselter Traffic kleiner Nachrichten im Normalbetrieb ist vergleichsweise günstig.

Verbrauchen inaktive MQTT-Clients trotzdem Broker-Ressourcen?

Ja. Ein inaktiver Client hält weiterhin einen Socket, Speicher für seine Sitzung und Subscriptions und sendet Keepalive-Pings, daher verbrauchen auch ruhige Flotten Kapazität.

Wie viele Verbindungen erlaubt der kostenlose Plan von ConnectMQ?

Der Plan Serverless (Free) erlaubt bis zu 25 gleichzeitige Verbindungen, der kostenpflichtige Serverless-Plan bis zu 1.000. Dedicated- und BYOC-Bereitstellungen werden für Ihren Workload dimensioniert.