Planeamento de taxa de transferência de SMS e TPS: dimensionamento de conexões SMPP para campanhas de alto volume.

TPS (transações por segundo) é o número de operações de envio de SMS que a sua plataforma conclui a cada segundo. Em SMPP, a taxa de transferência sustentada é determinada pela janela da sessão — a contagem de PDUs não confirmadas em trânsito — dividida pela latência de ida e volta até o SMSC: taxa de transferência ≈ janela ÷ RTT. Para ultrapassar o limite de uma única sessão, execute várias conexões paralelas.

O que significa TPS em SMS?

TPS — transações por segundo, usado como sinónimo de mensagens por segundo em mensagens A2P — mede quantas operações de envio de mensagens saem do seu sistema e são aceitas posteriormente a cada segundo. Em termos de SMPP, uma transação é um PDU submit_sm que o SMSC reconhece com um submit_sm_resp. TPS é a unidade em que todos os contratos, limites de taxa e planos de capacidade são definidos, portanto, a definição exata é importante: ela contabiliza os envios aceitos para entrega, não as mensagens confirmadas como entregues a um dispositivo — esse é um fluxo separado de relatório de entrega (DLR) que chega posteriormente como PDUs deliver_sm.

A distinção entre taxa de submissão e taxa de entrega é onde a maioria dos planeamentos de capacidade falha. Você pode submeter a 5.000 TPS enquanto um operador downstream só termina a 2.000; a diferença preenche uma fila em algum lugar. Planear a vazão significa planear toda a cadeia — o seu cliente, a sessão SMPP com a plataforma, a rota da plataforma até o gateway SMSC de destino e o limite de taxa A2P desse operador.

Como funciona na prática a taxa de transferência SMPP: janela e latência

SMPP é um protocolo TCP persistente e com estado. Você estabelece uma conexão uma única vez e transmite PDUs em ambas as direções por horas. A taxa de transferência numa única conexão não é determinada pela largura de banda — as PDUs SMS são minúsculas — mas por duas variáveis: a janela assíncrona e o tempo de ida e volta.

A janela é o número máximo de PDUs submit_sm que você pode enviar antes de precisar esperar por uma resposta submit_sm_resp. No modo síncrono, a janela é efetivamente 1: você envia, aguarda a resposta e envia novamente — portanto, uma única requisição lenta limita todo o fluxo. No modo assíncrono (com janela), você pode enviar até N solicitações sem bloqueio, e as respostas devolvem simultaneamente. Esse N é o tamanho da janela, negociado com a plataforma a cada vinculação.

Como um vínculo pode ter no máximo `window` PDUs pendentes, e cada PDU ocupa o canal por um tempo de ida e volta (RTT) antes do seu slot ser liberado, o limite máximo de um único vínculo é simplesmente a janela dividida pelo RTT:

1# Limite de throughput SMPP de vinculação única
2tps_por_vinculação = tamanho_da_janela / rtt_segundos
3 
4# Janela de 10 PDUs não confirmadas, 100 ms de ida e volta para o SMSC:
5tps_por_vinculação = 10 / 0,100 = 100 submit_sm/s
6 
7# Mesma janela, latência reduzida pela metade para 50 ms:
8tps_por_vinculação = 10 / 0,050 = 200 submit_sm/s
9 
10# Escala horizontalmente em N vinculações paralelas:
11total_tps = tps_por_vinculação * n_vinculações
12= 200 * 4 = 800 submit_sm/s

Duas alavancas decorrem disso. Ampliar a janela significa que mais PDUs ficam em trânsito por viagem de ida e volta. Diminuir o RTT — posicionando o seu cliente próximo à entrada da plataforma ou removendo os handshakes TLS por requisição, que é exatamente o que uma conexão SMPP persistente proporciona em comparação com uma requisição HTTP por chamada — faz com que cada slot seja reciclado mais rapidamente. Uma janela muito pequena prejudica um link de baixa latência; uma janela muito grande apenas armazena em buffer PDUs para as quais o SMSC não está preparado, aumentando a latência sem adicionar throughput.

Exemplo prático: janela e RTT para TPS, depois múltiplas vinculações.

Suponha que o seu cliente esteja na mesma região que a plataforma e meça um RTT de 80 ms sob carga. Com uma janela negociada de 50, uma única vinculação sustenta 50 ÷ 0,080 ≈ 625 TPS. Isso já é confortável para a maioria dos remetentes. Quando o seu pico exigir mais, você não busca uma janela cada vez maior — além de um certo ponto, ela apenas enfileira as solicitações — você adiciona vinculações. Quatro vinculações a 625 TPS cada fornecem aproximadamente 2.500 TPS agregados; a plataforma balanceia a carga das solicitações entre as sessões.

A última linha (10.000 TPS) fica bem dentro dos até 30.000 SMS/s que um único nó da BroadNet sustenta — alcançados não com uma única conexão excecional, mas com uma janela de conexão modesta, baixa latência e conexões horizontais. Modele a sua própria combinação na calculadora de TPS antes de se comprometer com uma taxa contratada, pois o cálculo determina quantas conexões a sua equipa de operações precisa executar e monitorizar.

TPS aprovisionado versus capacidade bruta

Existem dois valores de throughput e eles não são iguais. A capacidade bruta é o que o cálculo de janela e latência acima indica que as suas conexões podem atingir. O TPS aprovisionado (contratado) é a taxa que a sua conta está autorizada a enviar — um limite imposto pela plataforma para que um cliente não sobrecarregue uma rota partilhada ou acione os controlos de abuso de um operador. Se o seu contrato for de 500 TPS, abrir dez conexões simultâneas não resultará em 5.000; a plataforma limita a sua taxa ao valor aprovisionado e devolve respostas de limitação (ESME_RTHROTTLED) acima desse limite.

O dimensionamento de binds tem duas funções: aprovisionar TPS contratado suficiente para o seu pico real e configurar binds e janelas suficientes para atingir esse número aprovisionado, considerando a sua latência. Se o aprovisionamento for insuficiente, você terá a sua capacidade limitada; se o número de binds for excessivo para um contrato baixo, você desperdiçará recursos operacionais. Dimensione o contrato de acordo com a procura máxima primeiro e, em seguida, dimensione os binds para atendê-la.

O que está a prejudicar a sua produtividade real?

A fórmula fornece um limite máximo claro. Quatro fatores do mundo real reduzem a produção entregue abaixo desse limite, e todo planeamento de capacidade deve levá-los em consideração:

• Segmentação. Uma mensagem com mais de um segmento SMS é dividida e enviada como várias PDUs submit_sm — uma mensagem concatenada (UDH). Uma mensagem de marketing GSM-7 de 480 caracteres é composta por três segmentos, consumindo, portanto, três transações do seu orçamento de TPS, e não uma. O UCS-2 (árabe, emoji) reduz o limite de um único segmento para 70 caracteres, fazendo com que campanhas em idiomas não latinos consumam TPS mais rapidamente. Ao planear, considere os segmentos, não as mensagens.
• Enfileiramento e contrapressão. Quando você envia uma solicitação mais rápido do que um operador downstream consegue finalizá-la, as PDUs são enfileiradas. Uma plataforma saudável aplica contrapressão — limitando as respostas ou reduzindo a janela efetiva — em vez de simplesmente descartá-las silenciosamente. Considere o erro ESME_RTHROTTLED e o aumento da latência de resposta como sinais para diminuir a velocidade do loop de envio, e não como erros que devem ser repetidos indiscriminadamente.
• Limites de taxa por rota definidos pela operadora. A operadora de destino define o seu próprio limite de TPS A2P por remetente ou por vínculo, independentemente do seu contrato. Você pode enviar a 5.000 TPS, mas se a rede de destino aceitar 1.000 para o seu ID de remetente, a entrega real será limitada a 1.000 e o restante ficará em fila. Os limites de rota, e não o seu vínculo, geralmente definem a taxa de transferência real.
• Tráfego sustentado versus pico. Uma janela dimensionada para a carga média não absorverá um pico. O tráfego OTP é naturalmente instável — o lançamento de um produto ou uma transmissão aciona uma enxurrada de códigos de verificação em segundos — portanto, dimensione para o pico, não para a média diária.

Pico versus sustentado: dimensionamento para rajadas de OTP

A taxa de transações por segundo (TPS) sustentada é a sua taxa constante; o pico de TPS é o pior segundo que você precisa sobreviver sem que os códigos cheguem com atraso. Para OTP, o pico é o que importa — um código de verificação que chega depois que o utilizador desistiu falhou, mesmo que seja entregue posteriormente. As chegadas de OTP são intermitentes e correlacionadas: uma campanha de marketing, uma promoção relâmpago ou um evento regional no Conselho de Cooperação do Golfo (CCG) durante o Ramadã ou um feriado nacional podem concentrar os logins em poucos minutos. O tamanho limita e contrai o TPS a esse pico com margem de segurança, permitindo que a plataforma partilhada absorva o excesso por meio de filas, em vez de descartá-las.

É aqui também que o SMPP justifica o seu custo operacional em relação ao HTTP. Uma vinculação persistente remove o handshake TLS por requisição do caminho crítico, de modo que a latência permanece estável à medida que o volume aumenta — a propriedade desejada quando ocorre um pico de requisições. Equipas que não precisam desse perfil geralmente são melhor atendidas pela API de SMS via HTTPS; a compensação é entre a margem de throughput e a estabilidade da latência versus a simplicidade de integração.

Perguntas frequentes

O que é TPS em SMS?

TPS significa transações por segundo — o número de operações de envio de SMS que a sua plataforma aceita a cada segundo, usado como sinónimo de mensagens por segundo em mensagens A2P. Em SMPP, uma transação é um PDU submit_sm reconhecido por um submit_sm_resp. O TPS contabiliza os envios aceitos para entrega, não as mensagens confirmadas num aparelho, que são rastreadas separadamente por relatórios de entrega recebidos como PDUs deliver_sm.

Quantos SMS por segundo o SMPP pode enviar?

Não existe um número universal; uma única conexão SMPP suporta uma quantidade de mensagens por segundo igual a `window` ÷ `RTT`. Uma janela de 50 mensagens com um tempo de ida e volta de 80 ms resulta em cerca de 625 TPS por conexão, e a execução de múltiplas conexões paralelas aumenta ainda mais esse número, chegando a milhares. A taxa de transferência real é então limitada pelo seu TPS contratado e pelo limite de taxa A2P de cada operadora de destino, prevalecendo o menor valor.

Como dimensionar os vínculos SMPP e a janela para carga máxima?

Comece pelo seu pico de TPS, não pela média. Divida-o pelo limite máximo por vinculação (janela ÷ RTT) para obter o número de vinculações e, em seguida, aprovisione o TPS contratado para cobrir o pico com folga. Conte os segmentos em vez das mensagens — mensagens multipart e UCS-2 consomem transações extras — e adicione margem para picos de OTP. Modele a combinação numa calculadora de TPS antes de confirmar e, em seguida, realize testes de carga.

Referências

• Especificação do protocolo SMPP v3.4 — transmissão assíncrona, tamanho da janela e semântica de PDU: smpp.org
• Especificação do protocolo SMPP v5.0 — estado de congestionamento e comportamento de limitação de taxa: smpp.org
• GSMA — IR.71 Interconexão de Rede a Rede SMS e estrutura A2P: gsma.com
• BroadNet — guia de integração SMPP e a calculadora TPS para dimensionamento de vinculação.