Tests de charge

# Les bancs

Date : 24 juillet 2026 · Protocole : MQTT 3.1.1 · Outil : client de charge maison cmd/loadtest bâti sur le codec du projet, sans aucune bibliothèque MQTT tierce.

Les essais ont été menés sur deux bancs pour séparer le comportement propre du broker de l'influence de l'environnement : réseau contre boucle locale, matériel modeste contre matériel puissant.

# Synthèse

• Latence. Par le réseau, la latence de bout en bout « éditeur → broker → abonné » sous charge normale est d'environ 1 ms ; en boucle locale, elle est de 73 µs (~16× moins, le réseau ôté).
• Connexions. Par le réseau, le broker a tenu 10 000 sessions sans échec (au-delà, nous avons buté sur la limite de ports du client). Sur matériel puissant en boucle locale : 30 000 sans échec et ~41 000 lors d'une tentative à 50 000 (la limite d'une seule machine, non du broker).
• Ingestion. Le pic par le réseau a été de ≈277 000 messages/s ; en boucle locale l'ingestion est plus faible (≈185 000/s) car le générateur dispute les cœurs au broker.
• Fan-out (distribution). Sur matériel puissant, le broker a distribué ≈1 350 000 messages/s aux abonnés (fan-out ×100) contre ≈22 000/s par le réseau.
• Robustesse. Sur aucun banc le broker n'a planté ni ne s'est figé. En surcharge, les messages QoS 0 destinés aux abonnés en retard sont écartés proprement ; le journal du broker ne contient pas une seule erreur sur l'ensemble des essais.

# Capacité en connexions simultanées

Chaque connexion est un cycle complet CONNECT → CONNACK avec authentification ; la session est ensuite maintenue ouverte (vérifiée par PINGREQ).

Banc A — par le réseau

Banc B — boucle locale (montée progressive)

Analyse

• Par le réseau, jusqu'à 10 000 — aucun échec ; les 121 échecs à 15 000 sont l'épuisement des ports éphémères du client (16 384). C'est la limite du générateur, non celle du broker.
• En boucle locale, après élargissement de la plage de ports, le broker a tenu 30 000 sessions sans faute ; à 50 000, environ 41 000 restaient vivantes en fin de maintien — les deux côtés partagent une seule machine. Le journal du broker est resté propre du début à la fin, sans erreurs.
• Constat annexe. En boucle locale, une rafale de connexions trop brutale (1 000 dials simultanés) provoque un connection refused — la file d'attente d'acceptation déborde : sans délai réseau, tous les SYN arrivent en même temps. Une montée progressive (200 à la fois) supprime entièrement l'effet. Sur un réseau, la latence lisse la rafale d'elle-même.

# Débit d'ingestion

Un ensemble d'éditeurs publie aussi vite que possible ; on mesure la cadence d'ingestion du broker.

QoS 0 · charge utile de 64 octets

L'ingestion est plus élevée par le réseau — non parce que le broker du banc A serait plus rapide, mais parce que le générateur y tourne sur une machine distincte. En boucle locale, client et broker partagent les mêmes cœurs, ce qui plafonne la cadence globale.

QoS 1 (avec accusé PUBACK) · 64 o

Le client de test QoS 1 est synchrone (il attend un PUBACK après chaque message) et se trouve donc borné par l'aller-retour. En boucle locale, cet aller-retour est quasi nul, d'où le gain d'environ ×6. Cela montre clairement que les chiffres QoS 1 sont fixés par la latence réseau, non par le broker.

Balayage des tailles de message · QoS 0 · 50 éditeurs

Deux plafonds différents :

• Par le réseau, on bute sur la liaison vers ≈40 Mo/s : à mesure que le message grossit, les msg/s tombent tandis que les Mo/s restent près de la limite.
• En boucle locale, la liaison est énorme, donc le nombre de messages tient bon (~102 000/s à 50 connexions) et le volume monte à 104,6 Mo/s. Ici le goulot est le traitement par message (processeur), non les octets.

# Livraison de bout en bout

Un horodatage est inséré dans le corps du message ; on mesure la livraison réelle et la latence de bout en bout. Le fan-out désigne la livraison à chaque abonné dont le filtre correspond.

Banc A — par le réseau

Banc B — boucle locale

Analyse

• Latence sous charge normale : 1,17 ms par le réseau contre 73 µs en boucle locale. L'écart, c'est le trajet réseau.
• Distribution sous charge : la machine puissante a livré ≈1,35 million de messages/s aux abonnés (fan-out ×100) — deux ordres de grandeur au-dessus du banc réseau (22 k/s), où le broker comme la liaison sont modestes.
• Dans les scénarios à fort fan-out, le générateur devient lui aussi le goulot (tous les abonnés dans un processus sur une machine), les pics de livraison sont donc une borne inférieure de ce dont le broker est capable.

# Face à face

# Réserves méthodologiques

• La cadence d'ingestion n'est pas directement comparable entre les bancs : sur le banc B, générateur et broker partagent les cœurs ; sur le banc A, le générateur est une machine distincte.
• Sur chaque banc, la charge vient d'une seule machine cliente ; dans certains scénarios (fan-out important, dizaines de milliers de connexions) c'est cette machine, et non le broker, qui est le goulot.
• Le client de test QoS 1 est synchrone — les chiffres QoS 1 sous-estiment le potentiel du broker.
• Les métriques système du broker (processeur/mémoire pendant les essais) n'ont pas été relevées ; l'état du serveur est déduit de son journal (aucune erreur) et du comportement côté client.

# Reproduire

Chaque essai se lance depuis un unique binaire loadtest ; voici les commandes des trois modes.

go build -o loadtest ./cmd/loadtest

# Capacité en connexions (montée progressive contre file d'acceptation)
./loadtest -addr HOST:1883 -user myelx -pass *** \
    -mode conn -levels 1000,10000,30000,50000 -hold 3s -dial-concurrency 200

# Débit d'ingestion
./loadtest -addr HOST:1883 -user myelx -pass *** \
    -mode pub -pubs 10 -qos 0 -payload 64 -duration 10s

# Livraison de bout en bout et latence
./loadtest -addr HOST:1883 -user myelx -pass *** \
    -mode pubsub -subs 10 -pubs 10 -qos 0 -rate 100 -payload 64 -duration 10s