Messages MQTT par seconde : comment estimer et mesurer le débit

Estimer le nombre de messages MQTT par seconde est l'exercice de dimensionnement le plus utile que vous puissiez faire avant de choisir une offre de broker, et il prend moins d'une heure. Ce guide vous montre comment calculer les débits de messages entrants et sortants de votre flotte, tenir compte des pics et de la surcharge protocolaire, mesurer le trafic réel avec un court script et traduire les chiffres en décision d'offre.

Entrant, sortant et pourquoi les deux comptent

Un broker gère deux flux de messages :

• Entrant : les messages publiés par les clients vers le broker.
• Sortant : les copies que le broker livre aux abonnés correspondants.

Si chaque message a exactement un abonné, les deux sont égaux. Dans les systèmes réels, c'est rarement le cas. Un message de télémétrie lu par un tableau de bord, un historien et un service d'alerte produit trois livraisons sortantes. Une commande envoyée à un appareil en produit une. Un abonné à joker, comme un outil de débogage sur #, reçoit tout. Le sortant est souvent le chiffre le plus élevé : estimez donc toujours les deux.

Les formules de base

Trois suffisent :

1. Débit entrant (msg/s) = nombre d'éditeurs x messages par éditeur et par seconde
2. Débit sortant (msg/s) = débit entrant de chaque topic x nombre d'abonnés correspondants, additionné sur tous les topics
3. Bande passante (octets/s) = (entrant + sortant) x taille moyenne des messages, plus la surcharge protocolaire et TLS

La taille de message désigne ici le payload MQTT plus la chaîne du topic et quelques octets d'en-tête fixe. Pour une petite télémétrie, le topic peut être aussi volumineux que le payload, ce qui explique en partie l'existence des alias de topic de MQTT 5.

Pensez à la QoS lorsque vous raisonnez en paquets plutôt qu'en messages. La QoS 0 envoie un paquet par livraison. La QoS 1 ajoute un PUBACK pour chaque publication dans chaque sens. La QoS 2 utilise un échange en quatre paquets. Le nombre de messages ne change pas, mais le nombre de paquets et le travail du broker, si.

Un exemple chiffré

Prenons un site hypothétique avec trois types d'éditeurs. Ces chiffres sont illustratifs, pas des mesures.

Trois constats ressortent presque systématiquement d'un tel tableau :

• Quinze passerelles rapides génèrent l'essentiel du trafic, tandis que 120 capteurs lents pèsent à peine.
• Le sortant représente près de trois fois l'entrant, à cause de la diffusion.
• Le nombre de connexions, 270 clients plus les abonnés backend, peut être la première limite atteinte, bien avant que le débit de messages ne pose problème.

Planifier pour les pics, pas pour les moyennes

Les moyennes masquent les moments qui posent problème. Prévoyez explicitement une marge pour :

• Les vagues de reconnexions. Après une panne, les appareils se reconnectent ensemble et beaucoup vident en même temps leurs mesures en tampon.
• Les minuteurs synchronisés. Des appareils qui démarrent en même temps et publient toutes les 60 secondes publieront dans la même seconde. Ajoutez une gigue aléatoire à la première publication.
• Les rafales d'événements. Les alarmes s'enchaînent souvent en cascade : un défaut en déclenche des dizaines d'autres liées.
• Les changements d'équipe ou de planning. Des lignes de production qui démarrent ensemble créent des sauts de trafic.
• Les sessions de débogage. Une personne qui s'abonne à # dans un outil de bureau ajoute une copie complète de tout le trafic.

Une règle empirique simple consiste à dimensionner pour un pic de plusieurs fois votre moyenne, et à vérifier que les clients lissent leurs rafales grâce à une limitation de débit et à de la gigue.

Mesurer les débits de messages réels

Les estimations sont un point de départ ; la mesure vous garde lucide. Le script ci-dessous s'abonne à un filtre de topic et affiche toutes les cinq secondes les messages par seconde et les octets par seconde. Pointez-le vers votre propre broker avec des identifiants de production, ou essayez-le sur le serveur MQTT public gratuit, réservé aux tests et aux prototypes, avec un préfixe de topic unique.

# rate_meter.py - mesure les messages MQTT par seconde sur un filtre de topic
import sys
import threading
import time

import paho.mqtt.client as mqtt

HOST = "broker.connectmq.com"
FILTER = sys.argv[1] if len(sys.argv) > 1 else "connectmq/demo/r8m2/#"
WINDOW = 5

lock = threading.Lock()
count = 0
nbytes = 0
per_topic = {}

def on_connect(client, userdata, flags, reason_code, properties):
    print("connected:", reason_code, "- measuring", FILTER)
    client.subscribe(FILTER, qos=0)

def on_message(client, userdata, msg):
    global count, nbytes
    with lock:
        count += 1
        nbytes += len(msg.payload) + len(msg.topic)
        per_topic[msg.topic] = per_topic.get(msg.topic, 0) + 1

client = mqtt.Client(mqtt.CallbackAPIVersion.VERSION2,
                     client_id="rate-meter-r8m2", protocol=mqtt.MQTTv5)
# Pour votre broker privé, décommentez ces lignes et utilisez le port 8883 :
# client.username_pw_set("YOUR_USERNAME", "YOUR_PASSWORD")
# client.tls_set()
client.on_connect = on_connect
client.on_message = on_message
client.connect(HOST, 1883)
client.loop_start()

while True:
    time.sleep(WINDOW)
    with lock:
        msgs, size, top = count, nbytes, sorted(per_topic.items(), key=lambda kv: -kv[1])[:3]
        count = nbytes = 0
        per_topic.clear()
    print(f"{msgs / WINDOW:8.1f} msg/s  {size / WINDOW / 1024:8.2f} KB/s  top: {top}")

Pour générer du trafic de test dans un autre terminal :

for i in $(seq 1 200); do
  mosquitto_pub -h broker.connectmq.com -p 1883 -i rate-pub-r8m2 \
    -t "connectmq/demo/r8m2/sensor/$((i % 5))" -m "{\"v\":$i}"
  sleep 0.2
done

Le cadencement compte : le serveur MQTT public gratuit autorise 10 messages par seconde par client, gardez donc vos éditeurs de test en dessous. Lorsque vous mesurez un broker de production, exécutez l'outil de mesure comme un client distinct avec ses propres identifiants, et mesurez pendant une période chargée, pas en pleine nuit.

Faire correspondre le débit à une offre de broker

Une fois les chiffres en main, comparez-les aux limites des offres. Sur ConnectMQ, les limites à vérifier sont les suivantes :

Comment lire le tableau au regard de votre estimation :

1. Les connexions d'abord. Additionnez éditeurs, abonnés, tableaux de bord et outils. Ce chiffre départage généralement Serverless gratuit et payant.
2. Le plus gros message ensuite. Si un message, y compris un lot d'arriéré, dépasse 256 Ko, il vous faut l'offre payante ou des lots plus petits.
3. La QoS en troisième. Si un flux exige une livraison exactement une fois, il vous faut la QoS 2.
4. La répartition des consommateurs en quatrième. Si un seul abonné backend ne suit pas votre débit sortant, il vous faut des abonnements partagés pour répartir la charge entre plusieurs instances.
5. L'isolation en dernier. Si votre débit est élevé et soutenu, ou si vous ne pouvez pas accepter que l'activité d'autres tenants affecte la vôtre, envisagez Dedicated ou BYOC et communiquez à l'équipe vos chiffres d'entrant, de sortant et de pic.

Pour le comportement en cas d'atteinte des limites, lisez les quotas de connexion d'un broker MQTT. Pour une vue d'ensemble de la croissance d'un déploiement, consultez comment faire évoluer un broker MQTT et combien de connexions un broker MQTT peut supporter.

Comment réduire le débit de messages

Si votre estimation est plus élevée que souhaité, ces techniques réduisent le trafic sans perte d'information :

• Report par exception. Publiez lorsqu'une valeur sort d'une bande morte plutôt qu'à intervalle fixe.
• Regroupement d'échantillons. Envoyez un message contenant dix mesures plutôt que dix messages.
• Sous-échantillonnage en périphérie. Publiez des moyennes à la seconde plutôt que des échantillons bruts à haute fréquence lorsque les consommateurs n'ont pas besoin des données brutes.
• Abonnements ciblés. Supprimez les abonnés # inutiles, qui multiplient le trafic sortant.
• Payloads compacts. Des clés JSON plus courtes ou des encodages binaires comme Protobuf réduisent le nombre d'octets par message.
• Alias de topic. En MQTT 5, les alias remplacent les longues chaînes de topic répétées par un petit entier.

Démarrer avec ConnectMQ

ConnectMQ est un broker MQTT managé avec des limites claires par offre, un explorateur de topics en direct et un tableau de bord pour observer le trafic en temps réel. Créez un broker Serverless gratuit sur app.connectmq.com, sans carte bancaire, lancez l'outil de mesure dessus et choisissez l'offre que vos chiffres désignent. Pour l'ensemble des options d'hébergement, consultez le guide sur le broker MQTT cloud.

Questions fréquentes

Comment calculer les messages MQTT par seconde ?

Multipliez le nombre d'éditeurs par leur fréquence de publication pour obtenir le débit entrant, puis multipliez le débit entrant de chaque topic par son nombre d'abonnés pour obtenir le débit sortant. Ajoutez une marge pour les pics.

Pourquoi le trafic sortant est-il supérieur au trafic entrant ?

Chaque message publié est livré à chaque abonné correspondant : un message lu par trois services compte donc trois fois en sortie. Les abonnés à jokers accentuent encore ce phénomène.

La QoS influe-t-elle sur les messages par seconde ?

La QoS ne change pas le nombre de messages envoyés, mais les QoS 1 et 2 ajoutent des paquets d'acquittement et du travail pour le broker à chaque message. Utilisez la QoS 0 pour la télémétrie à haut débit où l'échantillon suivant remplace le précédent.

Quel débit de messages autorise le broker public de ConnectMQ ?

Le serveur MQTT public gratuit autorise 10 messages par seconde par client, avec 64 Ko par message. Les offres privées sont définies par le nombre de connexions, la taille des messages et les limites de QoS : comparez-les à votre estimation.