Estimar as mensagens MQTT por segundo é o exercício de dimensionamento mais útil que você pode fazer antes de escolher um plano de broker, e leva menos de uma hora. Este guia mostra como calcular as taxas de mensagens de entrada e saída da sua frota, considerar picos e overhead de protocolo, medir o tráfego real com um script curto e traduzir os números em uma decisão de plano.
Entrada, Saída e Por Que as Duas Importam
Um broker lida com dois fluxos de mensagens:
- Entrada (inbound): mensagens publicadas pelos clientes no broker.
- Saída (outbound): cópias que o broker entrega aos assinantes correspondentes.
Se toda mensagem tem exatamente um assinante, as duas são iguais. Em sistemas reais, raramente são. Uma mensagem de telemetria lida por um dashboard, um historiador e um serviço de alertas gera três entregas de saída. Um comando enviado a um dispositivo gera uma. Um assinante com curinga, como uma ferramenta de depuração em #, recebe tudo. A saída costuma ser o número maior, então estime sempre os dois.
As Fórmulas Básicas
Você só precisa de três:
- Taxa de entrada (msg/s) = número de publicadores x mensagens por publicador por segundo
- Taxa de saída (msg/s) = taxa de entrada em cada topic x número de assinantes correspondentes, somada entre os topics
- Banda (bytes/s) = (entrada + saída) x tamanho médio da mensagem, mais o overhead de protocolo e TLS
Aqui, tamanho da mensagem significa o payload MQTT mais a string do topic e alguns bytes de cabeçalho fixo. Em telemetria pequena, o topic pode ser tão grande quanto o payload, e esse é um dos motivos pelos quais existem os topic aliases do MQTT 5.
Lembre-se do QoS ao raciocinar em pacotes em vez de mensagens. QoS 0 envia um pacote por entrega. QoS 1 adiciona um PUBACK para cada publicação em cada direção. QoS 2 usa uma troca de quatro pacotes. O número de mensagens não muda, mas o número de pacotes e o trabalho do broker mudam.
Um Exemplo Prático
Considere uma instalação hipotética, por exemplo uma planta industrial em Campinas, com três tipos de publicadores. Os números são ilustrativos, não medições.
| Grupo de publicadores | Quantidade | Intervalo de publicação | Entrada msg/s | Assinantes por mensagem | Saída msg/s |
|---|---|---|---|---|---|
| Sensores ambientais | 120 | a cada 60 s | 2,0 | 2 (dashboard, historiador) | 4,0 |
| Gateways de máquinas | 15 | a cada 1 s | 15,0 | 3 (dashboard, historiador, alertas) | 45,0 |
| Status dos dispositivos | 135 | na mudança, cerca de a cada 10 min | 0,2 | 1 (monitor) | 0,2 |
| Total | 270 | 17,2 | 49,2 |
Três observações surgem de uma tabela como essa quase sempre:
- Quinze gateways rápidos geram a maior parte do tráfego, enquanto 120 sensores lentos mal aparecem.
- A saída é quase três vezes a entrada por causa do fan-out.
- O número de conexões, 270 clientes mais os assinantes do backend, pode ser o limite que você atinge primeiro, muito antes de a taxa de mensagens virar uma preocupação.
Planeje para Picos, Não para Médias
Médias escondem os momentos que causam problemas. Adicione margens explícitas para:
- Enxurradas de reconexão. Após uma indisponibilidade, os dispositivos reconectam juntos e muitos descarregam de uma vez as leituras armazenadas.
- Timers sincronizados. Dispositivos que iniciam ao mesmo tempo e publicam a cada 60 segundos vão publicar no mesmo segundo. Adicione jitter aleatório à primeira publicação.
- Rajadas de eventos. Alarmes costumam se encadear: uma falha dispara dezenas de alertas relacionados.
- Trocas de turno ou de programação. Linhas de produção que começam juntas criam degraus no tráfego.
- Sessões de depuração. Alguém assinando
#em uma ferramenta desktop adiciona uma cópia completa de todo o tráfego.
Uma regra prática simples é dimensionar para um pico várias vezes maior que a média e verificar se os clientes suavizam suas rajadas com limitação de taxa e jitter.
Medindo as Taxas Reais de Mensagens
Estimativas são um ponto de partida; a medição mantém você honesto. O script abaixo assina um filtro de topic e imprime mensagens por segundo e bytes por segundo a cada cinco segundos. Aponte-o para o seu próprio broker com credenciais de produção ou teste-o no servidor MQTT público com um prefixo de topic exclusivo, lembrando que ele serve para testes e protótipos, não para dados de produção.
# rate_meter.py - mede mensagens MQTT por segundo em um 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 o seu broker privado, descomente estas linhas e use a porta 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 gerar tráfego de teste em outro 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
O ritmo importa: o servidor MQTT público permite 10 mensagens por segundo por cliente, então mantenha os publicadores de teste abaixo disso. Ao medir um broker de produção, execute o medidor como um cliente separado, com credenciais próprias, e meça durante um período movimentado, não de madrugada.
Associando a Vazão a um Plano de Broker
Com os números em mãos, compare-os com os limites dos planos. Na ConnectMQ, os limites que você precisa verificar são:
| Plano | Conexões | QoS máximo | Tamanho máximo da mensagem | Shared subscriptions |
|---|---|---|---|---|
| Serverless (Free) | Até 25 | 1 | 256 KB | Não |
| Serverless (Paid) | Até 1.000 | 2 | 1 MB | Sim |
| Dedicated | Cluster isolado dimensionado com você | Definido com a equipe | Definido com a equipe | Definido com a equipe |
| BYOC | Na sua conta de nuvem, dimensionado com você | Definido com a equipe | Definido com a equipe | Definido com a equipe |
Como ler a tabela em relação à sua estimativa:
- Conexões primeiro. Some publicadores, assinantes, dashboards e ferramentas. Esse número geralmente decide entre o Serverless gratuito e o pago.
- Maior mensagem em segundo. Se qualquer mensagem, incluindo um lote de backlog, ultrapassar 256 KB, você precisa do plano pago ou de lotes menores.
- QoS em terceiro. Se algum fluxo exigir entrega exatamente uma vez, você precisa de QoS 2.
- Escalabilidade dos consumidores em quarto. Se um único assinante do backend não acompanha sua taxa de saída, você precisa de shared subscriptions para dividir a carga entre instâncias.
- Isolamento por último. Se sua vazão é alta e constante, ou se você não pode aceitar que a atividade de outros tenants afete a sua, converse sobre Dedicated ou BYOC e compartilhe com a equipe seus números de entrada, saída e pico.
Para o comportamento das cotas quando os limites são atingidos, leia cotas de conexão de broker MQTT. Para a visão mais ampla de como fazer uma implantação crescer, veja como escalar um broker MQTT e quantas conexões um broker MQTT suporta.
Formas de Reduzir a Taxa de Mensagens
Se a sua estimativa ficou acima do desejado, estas técnicas reduzem o tráfego sem perder informação:
- Reporte por exceção. Publique quando um valor mudar além de uma banda morta, em vez de seguir um timer fixo.
- Agrupe amostras. Envie uma mensagem com dez leituras em vez de dez mensagens.
- Reduza a amostragem na borda. Publique médias de um segundo em vez de amostras brutas de alta frequência quando os consumidores não precisarem dos dados brutos.
- Restrinja as assinaturas. Remova assinantes
#desnecessários, que multiplicam o tráfego de saída. - Use payloads compactos. Chaves JSON mais curtas ou codificações binárias como Protobuf reduzem os bytes por mensagem.
- Use topic aliases. No MQTT 5, os aliases reduzem strings longas e repetidas de topic a um pequeno inteiro.
Comece com a ConnectMQ
A ConnectMQ é um broker MQTT gerenciado com limites claros por plano, um explorador de topics em tempo real e um dashboard para acompanhar o tráfego enquanto ele flui. Crie um broker Serverless gratuito em app.connectmq.com, sem cartão de crédito, execute o medidor de taxa contra ele e escolha o plano que seus números indicarem. Para toda a gama de opções de hospedagem, veja o guia de broker MQTT na nuvem.
Perguntas frequentes
Como calculo as mensagens MQTT por segundo?
Multiplique o número de publicadores pela frequência com que cada um publica para obter a taxa de entrada; depois multiplique a taxa de entrada de cada topic pelo número de assinantes para obter a taxa de saída. Adicione uma margem para os picos.
Por que o tráfego de saída é maior que o de entrada?
Cada mensagem publicada é entregue a todos os assinantes correspondentes, então uma mensagem lida por três serviços conta três vezes na saída. Assinantes com curinga aumentam ainda mais esse número.
O QoS afeta as mensagens por segundo?
O QoS não muda quantas mensagens você envia, mas QoS 1 e 2 adicionam pacotes de confirmação e trabalho do broker para cada mensagem. Use QoS 0 para telemetria de alta frequência, em que a próxima amostra substitui a anterior.
Qual taxa de mensagens o servidor MQTT público da ConnectMQ permite?
O servidor MQTT público permite 10 mensagens por segundo por cliente, com até 64 KB por mensagem. Os planos privados são definidos por número de conexões, tamanho de mensagem e limites de QoS, então compare esses valores com a sua estimativa.



