Mensajes MQTT por segundo: cómo estimar y medir el rendimiento

Estimar los mensajes MQTT por segundo es el ejercicio de dimensionamiento más útil que puedes hacer antes de elegir un plan de broker, y lleva menos de una hora. Esta guía muestra cómo calcular las tasas de mensajes entrantes y salientes de tu flota, tener en cuenta los picos y la sobrecarga del protocolo, medir el tráfico real con un script breve y traducir las cifras en una decisión de plan.

Entrante, saliente y por qué importan ambos

Un broker gestiona dos flujos de mensajes:

• Entrante: mensajes que los clientes publican en el broker.
• Saliente: copias que el broker entrega a los suscriptores que coinciden.

Si cada mensaje tiene exactamente un suscriptor, ambos son iguales. En los sistemas reales rara vez lo son. Un mensaje de telemetría leído por un dashboard, un historian y un servicio de alertas produce tres entregas salientes. Un comando enviado a un dispositivo produce una. Un suscriptor con comodín, como una herramienta de depuración suscrita a #, lo recibe todo. El saliente suele ser la cifra mayor, así que estima siempre ambos.

Las fórmulas básicas

Solo necesitas tres:

1. Tasa entrante (msg/s) = número de publicadores x mensajes por publicador por segundo
2. Tasa saliente (msg/s) = tasa entrante de cada topic x número de suscriptores que coinciden, sumado para todos los topics
3. Ancho de banda (bytes/s) = (entrante + saliente) x tamaño medio de mensaje, más la sobrecarga del protocolo y de TLS

Aquí, el tamaño de mensaje es el payload MQTT más la cadena del topic y unos pocos bytes de cabecera fija. En telemetría pequeña, el topic puede ser tan grande como el payload, que es una de las razones por las que existen los topic aliases de MQTT 5.

Ten en cuenta el QoS cuando razones en paquetes en lugar de en mensajes. QoS 0 envía un paquete por entrega. QoS 1 añade un PUBACK por cada publicación en cada dirección. QoS 2 usa un intercambio de cuatro paquetes. El número de mensajes no cambia, pero sí el número de paquetes y el trabajo del broker.

Un ejemplo práctico

Imagina una planta hipotética en Monterrey con tres tipos de publicadores. Estas cifras son ilustrativas, no mediciones.

Casi siempre se extraen tres observaciones de una tabla como esta:

• Quince pasarelas rápidas generan la mayor parte del tráfico, mientras que 120 sensores lentos apenas se notan.
• El saliente es casi tres veces el entrante por el fan-out.
• El número de conexiones, 270 clientes más los suscriptores backend, puede ser el límite que alcances primero, mucho antes de que la tasa de mensajes sea un problema.

Planificar para los picos, no para las medias

Las medias ocultan los momentos que causan problemas. Añade márgenes explícitos para:

• Avalanchas de reconexión. Tras una caída, los dispositivos se reconectan a la vez y muchos vacían de golpe las lecturas almacenadas.
• Temporizadores sincronizados. Los dispositivos que arrancan a la vez y publican cada 60 segundos publicarán en el mismo segundo. Añade un jitter aleatorio a la primera publicación.
• Ráfagas de eventos. Las alarmas suelen encadenarse: un fallo dispara decenas de alertas relacionadas.
• Cambios de turno o de horario. Las líneas de producción que arrancan juntas crean saltos bruscos en el tráfico.
• Sesiones de depuración. Alguien que se suscribe a # en una herramienta de escritorio añade una copia completa de todo el tráfico.

Una regla práctica sencilla es dimensionar para un pico varias veces superior a la media y verificar que los clientes suavizan sus ráfagas con limitación de tasa y jitter.

Cómo medir las tasas de mensajes reales

Las estimaciones son un punto de partida; la medición te mantiene honesto. El script siguiente se suscribe a un filtro de topic e imprime cada cinco segundos los mensajes por segundo y los bytes por segundo. Apúntalo a tu propio broker con credenciales de producción, o pruébalo en el servidor MQTT público gratuito, pensado para pruebas y no para datos de producción, con un prefijo de topic único.

# rate_meter.py - mide los mensajes MQTT por segundo en un filtro 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)
# Para tu broker privado, descomenta estas líneas y usa el puerto 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}")

Para generar tráfico de prueba en otro 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

El ritmo importa: el servidor público permite 10 mensajes por segundo por cliente, así que mantén los publicadores de prueba por debajo de esa cifra. Cuando midas un broker de producción, ejecuta el medidor como un cliente separado con sus propias credenciales y mide durante un periodo de actividad, no de madrugada.

Cómo trasladar el rendimiento a un plan de broker

Una vez que tengas cifras, compáralas con los límites de los planes. En ConnectMQ, los límites que debes comprobar son:

Cómo leer la tabla frente a tu estimación:

1. Primero, las conexiones. Suma publicadores, suscriptores, dashboards y herramientas. Esa cifra suele decidir entre Serverless gratuito y de pago.
2. Segundo, el mensaje más grande. Si algún mensaje, incluido un lote de backlog, supera los 256 KB, necesitas el plan de pago o lotes más pequeños.
3. Tercero, el QoS. Si algún flujo requiere entrega exactamente una vez, necesitas QoS 2.
4. Cuarto, el escalado de consumidores. Si un único suscriptor backend no puede seguir el ritmo de tu tasa saliente, necesitas suscripciones compartidas para repartir la carga entre instancias.
5. Por último, el aislamiento. Si tu rendimiento es alto y sostenido, o no puedes aceptar que la actividad de otros inquilinos afecte a la tuya, valora Dedicated o BYOC y comparte con el equipo tus cifras de entrante, saliente y picos.

Para saber cómo se comportan las cuotas al alcanzar los límites, lee cuotas de conexión de un broker MQTT. Para una visión más amplia del crecimiento de un despliegue, consulta cómo escalar un broker MQTT y cuántas conexiones soporta un broker MQTT.

Formas de reducir la tasa de mensajes

Si tu estimación es más alta de lo que te gustaría, estas técnicas reducen el tráfico sin perder información:

• Informar por excepción. Publica cuando un valor cambie más allá de una banda muerta en lugar de con un temporizador fijo.
• Agrupar muestras. Envía un mensaje con diez lecturas en lugar de diez mensajes.
• Submuestrear en el edge. Publica medias de un segundo en lugar de muestras en bruto de alta frecuencia cuando los consumidores no necesiten los datos en bruto.
• Acotar las suscripciones. Elimina los suscriptores a # innecesarios, que multiplican el tráfico saliente.
• Usar payloads compactos. Claves JSON más cortas o codificaciones binarias como Protobuf reducen los bytes por mensaje.
• Usar topic aliases. En MQTT 5, los aliases reducen las cadenas de topic largas y repetidas a un entero pequeño.

Empieza con ConnectMQ

ConnectMQ es un broker MQTT gestionado con límites claros por plan, un explorador de topics en vivo y un dashboard para observar el tráfico mientras fluye. Crea un broker Serverless gratuito en app.connectmq.com, sin tarjeta de crédito, ejecuta el medidor de tasa contra él y elige el plan que indiquen tus cifras. Para ver todas las opciones de alojamiento, consulta la guía del broker MQTT en la nube.

Preguntas frecuentes

¿Cómo calculo los mensajes MQTT por segundo?

Multiplica el número de publicadores por la frecuencia con la que publica cada uno para obtener la tasa entrante, y luego multiplica la tasa entrante de cada topic por su número de suscriptores para obtener la tasa saliente. Añade un margen para los picos.

¿Por qué el tráfico saliente es mayor que el entrante?

Cada mensaje publicado se entrega a todos los suscriptores que coinciden, así que un mensaje leído por tres servicios cuenta tres veces en el saliente. Los suscriptores con comodines lo aumentan todavía más.

¿Afecta el QoS a los mensajes por segundo?

El QoS no cambia cuántos mensajes envías, pero QoS 1 y 2 añaden paquetes de confirmación y trabajo del broker por cada mensaje. Usa QoS 0 para telemetría de alta frecuencia en la que la siguiente muestra sustituye a la anterior.

¿Qué tasa de mensajes permite el servidor MQTT público gratuito de ConnectMQ?

El servidor MQTT público gratuito permite 10 mensajes por segundo por cliente, con 64 KB por mensaje, y está pensado para pruebas, no para datos de producción. Los planes privados se definen por número de conexiones, tamaño de mensaje y límites de QoS, así que compáralos con tu estimación.