Test de charge d'un broker MQTT : mesurer débit et latence

Un broker qui fonctionne avec un client de test peut quand même s'effondrer avec mille appareils. Faire un test de charge d'un broker MQTT répond à trois questions avant que la production ne le fasse : combien de connexions simultanées il accepte, combien de messages par seconde il peut router et quelle latence vos subscribers observent lorsqu'il est occupé.

Ce guide montre comment planifier un benchmark, l'exécuter avec deux outils open source et un script Python, puis lire les chiffres sans vous tromper vous-même.

Ce qu'il faut mesurer

Faites toujours le benchmark avec le même QoS, la même taille de payload et la même structure de topics que vos appareils. Un test qui publie des messages QoS 0 de 10 octets sur un seul topic ne dit rien d'une télémétrie QoS 1 de 2 Ko répartie sur 50 000 topics. Consultez les niveaux de QoS MQTT pour voir comment chaque niveau modifie le nombre de paquets.

Choisir la bonne cible

Ne lancez jamais un benchmark lourd contre une sandbox publique partagée : les chiffres n'ont aucun sens (vous êtes en concurrence avec tous les autres utilisateurs) et les opérateurs vous brideront ou vous bloqueront. Faites-y un smoke test, puis dirigez la charge vers une instance que vous contrôlez.

Dans les exemples ci-dessous, nous utilisons broker.connectmq.com ; remplacez l'hôte, le port et les identifiants par ceux de votre propre instance.

1. emqtt-bench

emqtt-bench est un outil écrit en Erlang capable d'ouvrir des dizaines de milliers de connexions depuis une seule machine. Le plus simple est de le lancer avec Docker :

docker run --rm -it emqx/emqtt-bench conn \
  -h broker.connectmq.com -p 1883 \
  -c 2000 -R 200 \
  -u "$MQTT_USER" -P "$MQTT_PASS"

Mesurez ensuite le débit avec un groupe de subscribers et un groupe de publishers qui tournent en même temps :

docker run --rm -it emqx/emqtt-bench sub \
  -h broker.connectmq.com -p 1883 \
  -c 100 -t 'bench/%i/#' -q 1

docker run --rm -it emqx/emqtt-bench pub \
  -h broker.connectmq.com -p 1883 \
  -c 100 -I 10 -t 'bench/%i/data' -s 256 -q 1

%i est remplacé par l'index du client : chaque publisher a donc son propre topic et son propre subscriber, un schéma de télémétrie un-à-un réaliste. 100 publishers × 100 msg/s donnent un objectif de 10 000 messages par seconde. emqtt-bench affiche chaque seconde les taux d'envoi et de réception ; si le taux reçu prend du retard sur le taux envoyé, le goulet d'étranglement est le broker (ou votre réseau).

2. mqtt-benchmark (Go)

Si vous préférez un binaire unique, mqtt-benchmark publie un nombre fixe de messages et fournit des statistiques de débit et de latence :

go install github.com/krylovsk/mqtt-benchmark@latest

mqtt-benchmark \
  --broker tcp://broker.connectmq.com:1883 \
  --clients 50 --count 1000 --size 512 --qos 1 \
  --topic bench/go --format text

Le résumé final indique les messages par seconde par client, le débit agrégé ainsi que la moyenne et l'écart type des temps de publication : un moyen rapide de comparer deux brokers ou deux configurations.

3. Un script de latence fiable

Les outils de débit mesurent la vitesse à laquelle les messages entrent. Les utilisateurs ressentent la vitesse à laquelle ils sortent. Ce script Python (paho-mqtt 2.x) intègre l'heure d'envoi dans chaque payload et calcule les percentiles de bout en bout côté subscriber :

import json, statistics, time, uuid
import paho.mqtt.client as mqtt

HOST, PORT = "broker.connectmq.com", 1883
TOPIC = f"bench/{uuid.uuid4().hex[:8]}/latency"
N, RATE = 2000, 200          # messages, messages par seconde
samples = []

def on_message(client, userdata, msg):
    sent = json.loads(msg.payload)["t"]
    samples.append((time.perf_counter() - sent) * 1000)

sub = mqtt.Client(mqtt.CallbackAPIVersion.VERSION2)
sub.on_message = on_message
sub.connect(HOST, PORT)
sub.subscribe(TOPIC, qos=1)
sub.loop_start()

pub = mqtt.Client(mqtt.CallbackAPIVersion.VERSION2)
pub.connect(HOST, PORT)
pub.loop_start()
time.sleep(1)                # laisser l'abonnement s'établir

for i in range(N):
    pub.publish(TOPIC, json.dumps({"i": i, "t": time.perf_counter()}), qos=1)
    time.sleep(1 / RATE)

time.sleep(3)
samples.sort()
p = lambda q: samples[int(len(samples) * q) - 1]
print(f"received {len(samples)}/{N}")
print(f"p50 {p(0.50):.1f} ms  p95 {p(0.95):.1f} ms  p99 {p(0.99):.1f} ms  max {samples[-1]:.1f} ms")
print(f"mean {statistics.mean(samples):.1f} ms")

Comme le publisher et le subscriber tournent dans le même processus, ils partagent la même horloge : aucune dérive NTP dans le résultat. Lancez-le une fois au repos et une fois pendant qu'emqtt-bench martèle le broker : la différence est la latence que vos appareils verront en pointe.

Lire les résultats

• Reçus < envoyés en QoS 0 signifie que le broker ou le client a abandonné des messages sous la pression. Relancez en QoS 1 pour savoir s'il s'agit d'un problème de livraison ou de capacité.
• Un p99 très supérieur au p50 indique des pauses de garbage collection, une persistance sur disque ou un lien réseau saturé. Vérifiez le CPU du broker et celui du générateur de charge : une machine de benchmark à fond est le faux résultat le plus courant.
• Le test de connexions bloque sur un nombre rond (1 024, 4 096, 65 535) : vous avez atteint une limite de descripteurs de fichiers ou de ports éphémères sur le générateur de charge, pas sur le broker. Augmentez ulimit -n ou répartissez la charge sur plusieurs machines ou IP sources.
• Des déconnexions pendant le test : cherchez des timeouts de keep alive ou les limites d'inflight / de file d'attente par client du broker. Voir keep alive MQTT et erreurs de connexion.

Une checklist de test de charge reproductible

1. Testez d'abord la connectivité avec le client MQTT en ligne ou avec mosquitto_pub / mosquitto_sub.
2. Figez le scénario : nombre de clients, QoS, taille de payload, structure des topics, retained ou non.
3. Montez en charge progressivement (10 %, 50 %, 100 %, 150 % du pic attendu) et maintenez chaque palier quelques minutes.
4. Enregistrez le CPU, la mémoire et le nombre de connexions du broker à côté des chiffres côté client.
5. Répétez le test deux fois ; ne faites confiance qu'aux résultats reproductibles.
6. Relancez-le après chaque mise à jour ou changement de configuration du broker.

Faites d'abord un smoke test dans votre navigateur

Le test de charge transforme « ça marche sur mon portable » en un chiffre sur lequel vous pouvez planifier la capacité. Commencez petit, mesurez la latence là où se trouvent vos utilisateurs et gardez les scripts dans votre dépôt pour que le prochain benchmark prenne des minutes plutôt que des jours.

Questions fréquentes