Pruebas de carga

# Los bancos

Fecha: 24 de julio de 2026 · Protocolo: MQTT 3.1.1 · Herramienta: cliente de carga propio cmd/loadtest construido sobre el códec del proyecto, sin bibliotecas MQTT de terceros.

Se probó en dos bancos para separar el comportamiento propio del broker de la influencia del entorno: red frente a bucle local, hardware modesto frente a hardware potente.

# Resumen ejecutivo

• Latencia. Por red, la latencia de extremo a extremo «publicador → broker → suscriptor» con carga normal ronda 1 ms; por bucle local es de 73 µs (~16 veces menos, sin la red).
• Conexiones. Por red el broker mantuvo 10 000 sesiones sin fallos (más allá topamos con el límite de puertos del cliente). En hardware potente por bucle local: 30 000 sin fallos y ~41 000 en un intento de 50 000 (el límite de una sola máquina, no del broker).
• Ingesta. El pico por red fue de ≈277 000 mensajes/s; por bucle local la ingesta es menor (≈185 000/s) porque el generador compite con el broker por los núcleos.
• Abanico (encaminamiento). En hardware potente el broker entregó ≈1 350 000 mensajes/s a los suscriptores (abanico ×100) frente a ≈22 000/s por red.
• Robustez. En ningún banco el broker se cayó ni se quedó colgado. En sobrecarga, los mensajes QoS 0 hacia suscriptores rezagados se descartan de forma ordenada; el registro del broker no contiene ni un solo error en todas las pruebas.

# Capacidad de conexiones simultáneas

Cada conexión es un ciclo completo CONNECT → CONNACK con autenticación; después la sesión se mantiene abierta (comprobada con PINGREQ).

Banco A — por red

Banco B — bucle local (subida gradual)

Análisis

• Por red, hasta 10 000 sin un solo fallo; los 121 fallos a 15 000 son agotamiento de los puertos efímeros del cliente (16 384). Es el límite del generador, no del broker.
• Por bucle local, tras ampliar el rango de puertos, el broker mantuvo 30 000 sesiones sin defecto; a 50 000 quedaban vivas unas 41 000 al final del periodo de retención, porque ambos lados comparten una máquina. El registro del broker se mantuvo limpio en todo momento, sin errores.
• Hallazgo lateral. Por bucle local, una ráfaga de conexiones demasiado brusca (1000 dials simultáneos) provoca connection refused: la cola de aceptación se desborda, porque sin retardo de red todos los SYN llegan a la vez. Una subida gradual (200 cada vez) elimina el efecto por completo. En una red, la latencia suaviza la ráfaga por sí sola.

# Rendimiento de ingesta

Un conjunto de publicadores publica lo más rápido posible; se mide el ritmo de ingesta del broker.

QoS 0 · carga útil de 64 bytes

La ingesta es mayor por red, no porque el broker del banco A sea más rápido, sino porque allí el generador corre en una máquina aparte. Por bucle local, cliente y broker comparten los mismos núcleos, lo que limita el ritmo conjunto.

QoS 1 (con confirmación PUBACK) · 64 B

El cliente de prueba de QoS 1 es síncrono (espera un PUBACK tras cada mensaje), así que queda limitado por el ida y vuelta. Por bucle local ese ida y vuelta es casi nulo, de ahí la mejora de unas 6 veces. Esto muestra con claridad que las cifras de QoS 1 las fija la latencia de red, no el broker.

Barrido de tamaños de mensaje · QoS 0 · 50 publicadores

Dos techos distintos:

• Por red topamos con el enlace en torno a 40 MB/s: al crecer el mensaje, los msg/s caen mientras los MB/s se mantienen cerca del límite.
• Por bucle local el enlace es enorme, así que el número de mensajes se mantiene (~102 000/s con 50 conexiones) y el volumen sube a 104,6 MB/s. Aquí el cuello de botella es el procesamiento por mensaje (procesador), no los bytes.

# Entrega de extremo a extremo

Se incrusta una marca de tiempo en el cuerpo del mensaje; se mide la entrega real y la latencia de extremo a extremo. Abanico significa entrega a cada suscriptor cuyo filtro coincida.

Banco A — por red

Banco B — bucle local

Análisis

• Latencia con carga normal: 1,17 ms por red frente a 73 µs por bucle local. La diferencia es el trayecto de red.
• Encaminamiento bajo carga: la máquina potente entregó ≈1,35 millones de mensajes/s a los suscriptores (abanico ×100), dos órdenes de magnitud por encima del banco de red (22 mil/s), donde tanto el broker como el enlace son pequeños.
• En escenarios de gran abanico el generador se convierte también en cuello de botella (todos los suscriptores en un proceso y una máquina), así que las cifras pico de entrega son una cota inferior de lo que el broker puede dar.

# Cara a cara

# Salvedades metodológicas

• El ritmo de ingesta no es directamente comparable entre bancos: en el banco B generador y broker comparten núcleos; en el banco A el generador es una máquina aparte.
• En cada banco la carga procede de una sola máquina cliente; en algunos escenarios (gran abanico, decenas de miles de conexiones) el cuello de botella es esa máquina y no el broker.
• El cliente de prueba de QoS 1 es síncrono, así que las cifras de QoS 1 subestiman el potencial del broker.
• No se registraron las métricas de sistema del broker (procesador y memoria durante las pruebas); el estado del servidor se deduce de su registro (sin errores) y del comportamiento del lado cliente.

# Reproducir

Cada prueba se lanza desde un único binario loadtest; abajo están las órdenes de los tres modos.

go build -o loadtest ./cmd/loadtest

# Capacidad de conexiones (subida gradual frente a la cola de aceptación)
./loadtest -addr HOST:1883 -user myelx -pass *** \
    -mode conn -levels 1000,10000,30000,50000 -hold 3s -dial-concurrency 200

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

# Entrega de extremo a extremo y latencia
./loadtest -addr HOST:1883 -user myelx -pass *** \
    -mode pubsub -subs 10 -pubs 10 -qos 0 -rate 100 -payload 64 -duration 10s