Lasttests

# Prüfstände

Datum: 24. Juli 2026 · Protokoll: MQTT 3.1.1 · Werkzeug: eigener Lastclient cmd/loadtest auf Basis des projekteigenen Codecs, ohne fremde MQTT-Bibliothek.

Getestet wurde auf zwei Prüfständen, um das Verhalten des Brokers vom Einfluss der Umgebung zu trennen: Netzwerk gegen Loopback, bescheidene gegen starke Hardware.

# Zusammenfassung

• Latenz. Über das Netzwerk beträgt die Ende-zu-Ende-Latenz „Publisher → Broker → Subscriber“ bei normaler Last etwa 1 ms; über Loopback sind es 73 µs (~16× weniger, ohne Netzwerk).
• Verbindungen. Über das Netzwerk hielt der Broker 10 000 Sitzungen ohne Ausfälle (darüber hinaus stießen wir an die Portgrenze des Clients). Auf starker Hardware über Loopback: 30 000 ohne Ausfälle und ~41 000 bei einem Versuch mit 50 000 (die Grenze einer einzelnen Maschine, nicht des Brokers).
• Aufnahme. Der Spitzenwert über das Netzwerk lag bei ≈277 000 Nachrichten/s; über Loopback ist die Aufnahme geringer (≈185 000/s), weil der Generator mit dem Broker um Kerne konkurriert.
• Fan-out (Verteilung). Auf starker Hardware stellte der Broker ≈1 350 000 Nachrichten/s an Abonnenten zu (Fan-out ×100) gegenüber ≈22 000/s über das Netzwerk.
• Robustheit. Auf keinem Prüfstand stürzte der Broker ab oder blieb hängen. Bei Überlast werden QoS-0-Nachrichten an nachhinkende Abonnenten geordnet verworfen; das Broker-Log enthält über alle Läufe hinweg nicht einen einzigen Fehler.

# Kapazität an gleichzeitigen Verbindungen

Jede Verbindung ist ein vollständiger Zyklus CONNECT → CONNACK mit Authentifizierung; anschließend wird die Sitzung offen gehalten (mit PINGREQ geprüft).

Prüfstand A — über das Netzwerk

Prüfstand B — Loopback (stufenweiser Aufbau)

Analyse

• Über das Netzwerk bis 10 000 — kein einziger Ausfall; die 121 Fehlschläge bei 15 000 sind erschöpfte ephemere Ports des Clients (16 384). Das ist die Grenze des Generators, nicht des Brokers.
• Über Loopback hielt der Broker nach Erweiterung des Portbereichs 30 000 Sitzungen fehlerfrei; bei 50 000 waren am Ende des Haltens noch etwa 41 000 am Leben — beide Seiten teilen sich eine Maschine. Das Broker-Log blieb durchgehend sauber, ohne Fehler.
• Nebenbefund. Über Loopback löst ein zu scharfer Verbindungsstoß (1 000 gleichzeitige dials) ein connection refused aus — der Accept-Backlog läuft über: ohne Netzwerkverzögerung treffen alle SYN gleichzeitig ein. Ein stufenweiser Aufbau (200 auf einmal) beseitigt den Effekt vollständig. Über ein Netzwerk glättet die Latenz den Stoß von selbst.

# Aufnahmedurchsatz

Ein Pool von Publishern veröffentlicht so schnell wie möglich; gemessen wird die Aufnahmerate des Brokers.

QoS 0 · 64 Byte Payload

Die Aufnahme ist über das Netzwerk höher — nicht weil der Broker auf Prüfstand A schneller wäre, sondern weil der Generator dort auf einer eigenen Maschine läuft. Über Loopback teilen sich Client und Broker dieselben Kerne, was die gemeinsame Rate deckelt.

QoS 1 (mit PUBACK-Bestätigung) · 64 B

Der Testclient für QoS 1 arbeitet synchron (er wartet nach jeder Nachricht auf ein PUBACK) und ist damit an die Umlaufzeit gebunden. Über Loopback ist die Umlaufzeit nahezu null, daher der Gewinn um das ~6-Fache. Das zeigt deutlich, dass die QoS-1-Zahlen von der Netzlatenz bestimmt werden und nicht vom Broker.

Durchlauf über Nachrichtengrößen · QoS 0 · 50 Publisher

Zwei verschiedene Obergrenzen:

• Über das Netzwerk stoßen wir bei ≈40 MB/s an die Leitung: Wächst die Nachricht, fällt msg/s, während MB/s nahe am Limit bleibt.
• Über Loopback ist die Leitung riesig, also bleibt die Nachrichtenzahl konstant (~102 000/s bei 50 Verbindungen) und das Volumen steigt auf 104,6 MB/s. Hier ist die Verarbeitung je Nachricht (CPU) der Engpass, nicht die Bytes.

# Ende-zu-Ende-Zustellung

In den Nachrichtenrumpf wird ein Zeitstempel eingebettet; gemessen werden die tatsächliche Zustellung und die Ende-zu-Ende-Latenz. Fan-out bedeutet die Zustellung an jeden Abonnenten, dessen Filter passt.

Prüfstand A — über das Netzwerk

Prüfstand B — Loopback

Analyse

• Latenz bei normaler Last: 1,17 ms über das Netzwerk gegenüber 73 µs über Loopback. Der Unterschied ist der Netzwerkweg.
• Verteilung unter Last: Die starke Maschine stellte ≈1,35 Millionen Nachrichten/s an Abonnenten zu (Fan-out ×100) — zwei Größenordnungen über dem Netzwerk-Prüfstand (22 Tsd./s), wo sowohl Broker als auch Leitung klein sind.
• In Szenarien mit hohem Fan-out wird auch der Generator zum Engpass (alle Abonnenten in einem Prozess auf einer Maschine), daher sind die Spitzenwerte der Zustellung eine Untergrenze dessen, was der Broker kann.

# Direkter Vergleich

# Vorbehalte zur Methodik

• Die Aufnahmerate ist zwischen den Prüfständen nicht direkt vergleichbar: Auf Prüfstand B teilen sich Generator und Broker die Kerne; auf Prüfstand A ist der Generator eine eigene Maschine.
• Die Last kommt auf jedem Prüfstand von einer einzigen Clientmaschine; in manchen Szenarien (großes Fan-out, Zehntausende Verbindungen) ist diese Maschine der Engpass und nicht der Broker.
• Der Testclient für QoS 1 arbeitet synchron — die QoS-1-Zahlen bleiben hinter dem Möglichen des Brokers zurück.
• Systemkennwerte des Brokers (CPU/RAM während der Läufe) wurden nicht erfasst; der Zustand des Servers wird aus seinem Log (keine Fehler) und aus dem Verhalten der Clientseite geschlossen.

# Nachvollziehen

Jeder Lauf wird aus einer einzigen loadtest-Binärdatei gestartet; nachfolgend die Befehle für die drei Modi.

go build -o loadtest ./cmd/loadtest

# Verbindungskapazität (stufenweiser Aufbau gegen Accept-Backlog)
./loadtest -addr HOST:1883 -user myelx -pass *** \
    -mode conn -levels 1000,10000,30000,50000 -hold 3s -dial-concurrency 200

# Aufnahmedurchsatz
./loadtest -addr HOST:1883 -user myelx -pass *** \
    -mode pub -pubs 10 -qos 0 -payload 64 -duration 10s

# Ende-zu-Ende-Zustellung und Latenz
./loadtest -addr HOST:1883 -user myelx -pass *** \
    -mode pubsub -subs 10 -pubs 10 -qos 0 -rate 100 -payload 64 -duration 10s