Pianificazione del throughput SMS e TPS: dimensionamento dei binding SMPP per campagne ad alto volume.

Il TPS (transazioni al secondo) indica il numero di operazioni di invio SMS completate dalla piattaforma ogni secondo. Su SMPP, la velocità di trasmissione sostenuta è determinata dalla finestra di sessione (il numero di PDU non confermate in transito) divisa per la latenza di andata e ritorno verso l'SMSC: velocità di trasmissione ≈ finestra ÷ RTT. Per superare il limite di una singola sessione, è necessario eseguire più connessioni in parallelo.

Cosa significa TPS negli SMS

TPS (transazioni al secondo, usato in modo intercambiabile con messaggi al secondo nella messaggistica A2P) misura quante operazioni di invio di messaggi lasciano il sistema e vengono accettate a valle ogni secondo. In termini SMPP, una transazione è una PDU submit_sm che l'SMSC conferma con una submit_sm_resp. TPS è l'unità in cui sono scritti tutti i contratti, i limiti di velocità e i piani di capacità, quindi è importante definirla con precisione: conta gli invii accettati per la consegna, non i messaggi confermati consegnati a un dispositivo mobile, che rappresentano un flusso di consegna-ricezione (DLR) separato che arriva in seguito come PDU deliver_sm.

La distinzione tra velocità di invio e velocità di consegna è il punto in cui la maggior parte dei piani di capacità fallisce. È possibile inviare a 5.000 TPS mentre un operatore a valle termina solo a 2.000; il divario riempie una coda da qualche parte. Pianificare il throughput significa pianificare l'intera catena: il client, la sessione SMPP verso la piattaforma, il percorso della piattaforma verso il gateway SMSC di terminazione e il limite massimo di velocità A2P di tale operatore.

Come funziona effettivamente il throughput SMPP: finestra temporale e latenza

SMPP è un protocollo TCP persistente e con stato. Si effettua una singola connessione e si trasmettono PDU in entrambe le direzioni per ore. La velocità di trasmissione per una singola connessione non è determinata dalla larghezza di banda (le PDU SMS sono minuscole), ma da due variabili: la finestra asincrona e il tempo di andata e ritorno.

La finestra rappresenta il numero massimo di PDU submit_sm che è possibile inviare prima di dover attendere la risposta da submit_sm_resp. In modalità sincrona, la finestra è effettivamente pari a 1: si invia, si attende la risposta e si invia di nuovo, quindi un singolo ciclo di attesa rallenta tutto. In modalità asincrona (con finestra) è possibile inviare fino a N richieste senza bloccarsi e le risposte vengono inviate contemporaneamente. N rappresenta la dimensione della finestra, negoziata con la piattaforma ad ogni connessione.

Poiché un collegamento può avere al massimo `window` PDU in sospeso e ogni PDU occupa il tubo per un tempo di andata e ritorno (RTT) prima che il suo slot si liberi, il limite massimo di un singolo collegamento è semplicemente la finestra divisa per l'RTT:

1# Limite massimo di throughput SMPP per singola connessione
2tps_per_bind = dimensione_finestra / rtt_secondi
3 
4# Finestra di 10 PDU non agganciate, 100 ms di tempo di andata e ritorno verso l'SMSC:
5tps_per_bind = 10 / 0,100 = 100 submit_sm/s
6 
7# Stessa finestra, latenza dimezzata a 50 ms:
8tps_per_bind = 10 / 0,050 = 200 submit_sm/s
9 
10# Scalabilità orizzontale su N connessioni parallele:
11total_tps = tps_per_bind * n_binds
12 
13= 200 * 4 = 800 submit_sm/s

Da ciò derivano due leve. Ampliando la finestra, un maggior numero di PDU rimangono in transito per ogni round trip. Riducendo l'RTT (Round Trip Time), ad esempio posizionando il client vicino al punto di ingestione della piattaforma o eliminando gli handshake TLS per richiesta, che è esattamente ciò che un binding SMPP persistente offre rispetto a una richiesta HTTP per chiamata, ogni slot si ricicla più velocemente. Una finestra troppo piccola penalizza un collegamento a bassa latenza; una finestra troppo grande si limita a memorizzare in un buffer le PDU per cui l'SMSC non è pronto, aumentando la latenza senza incrementare la velocità di trasmissione.

Esempio pratico: finestra e RTT a TPS, quindi più associazioni

Supponiamo che il tuo client si trovi nella stessa regione della piattaforma e misuri un RTT di 80 ms sotto carico. Con una finestra negoziata di 50, una singola connessione supporta 50 ÷ 0,080 ≈ 625 TPS. Questo è già sufficiente per la maggior parte dei mittenti. Quando il picco richiede di più, non si cerca di aumentare ulteriormente la finestra (oltre un certo punto si finisce solo per mettere in coda le richieste), ma si aggiungono connessioni. Quattro connessioni da 625 TPS ciascuna forniscono circa 2.500 TPS complessivi; la piattaforma bilancia il carico delle richieste tra le sessioni.

La riga inferiore (10.000 TPS) resta ampiamente entro i 30.000 SMS/sec che un singolo nodo BroadNet sostiene, raggiunti non con un singolo binding eccezionale, ma con una finestra di connessione modesta, bassa latenza e binding orizzontali. Calcola la tua combinazione personalizzata nel calcolatore TPS prima di impegnarti in una tariffa contrattuale, perché i calcoli determinano quanti binding il tuo team operativo dovrà eseguire e monitorare.

TPS fornito rispetto alla capacità grezza

Esistono due valori di throughput e non sono uguali. La capacità grezza è ciò che, secondo i calcoli di finestra e latenza sopra riportati, i tuoi bind potrebbero raggiungere. Il TPS (Transaction Per Second) previsto (contrattuale) è la velocità a cui il tuo account è autorizzato a inviare dati: un limite imposto dalla piattaforma per evitare che un singolo cliente sovraccarichi una rotta condivisa o attivi i controlli anti-abuso dell'operatore. Se il tuo contratto prevede 500 TPS, l'apertura di dieci bind wide non ti porterà a 5.000; la piattaforma ti limita al valore previsto e restituisce risposte di limitazione (ESME_RTHROTTLED) se il valore supera tale soglia.

Il dimensionamento dei bind ha quindi due scopi: allocare un numero sufficiente di TPS contrattualizzati per il picco reale e configurare un numero sufficiente di bind e una finestra temporale adeguata per raggiungere effettivamente il numero allocato, tenendo conto della latenza. Un dimensionamento insufficiente comporta una limitazione della velocità; un numero eccessivo di bind rispetto a un contratto di basso livello comporta uno spreco di risorse operative. Dimensionare prima il contratto in base alla domanda di picco, quindi dimensionare i bind per raggiungerla.

Cosa incide sulla tua produttività effettiva?

La formula definisce un limite massimo preciso. Quattro fattori concreti, tuttavia, possono far scendere la velocità di trasmissione effettiva al di sotto di tale limite, e ogni piano di capacità dovrebbe tenerne conto:

• Segmentazione. Un messaggio più lungo di un segmento SMS viene suddiviso e inviato come più PDU submit_sm, ovvero un messaggio concatenato (UDH). Un messaggio di marketing GSM-7 di 480 caratteri è composto da tre segmenti, quindi consuma tre transazioni del budget TPS, non una. UCS-2 (arabo, emoji) riduce il limite del singolo segmento a 70 caratteri, quindi le campagne non latine consumano TPS più rapidamente. In fase di pianificazione, è importante contare i segmenti, non i messaggi.
• Gestione delle code e contropressione. Quando si invia un PDU più velocemente di quanto un operatore a valle riesca a terminarlo, i PDU si mettono in coda. Una piattaforma efficiente applica una contropressione, limitando le risposte o riducendo la finestra effettiva, anziché scartarli silenziosamente. Considerate ESME_RTHROTTLED e l'aumento della latenza di risposta come segnali per rallentare il ciclo di invio, non come errori da ritentare indiscriminatamente.
• Limiti di velocità dell'operatore per tratta. L'operatore di terminazione imposta il proprio limite di TPS A2P per mittente o per associazione, indipendentemente dal contratto. È possibile inviare a 5.000 TPS, ma se la rete di destinazione accetta 1.000 per il proprio ID mittente, la consegna effettiva avviene a un ritmo di 1.000 e il resto viene messo in coda. I limiti a livello di tratta, non l'associazione, spesso definiscono la velocità di trasmissione effettiva.
• Traffico sostenuto contro traffico di picco. Una finestra dimensionata per il carico medio non è in grado di assorbire un picco. Il traffico OTP è per sua natura soggetto a picchi: il lancio di un prodotto o una trasmissione genera una valanga di codici di verifica in pochi secondi, quindi è necessario dimensionare la finestra in base al picco, non alla media giornaliera.

Picco contro sostenuto: dimensionamento per i picchi di OTP

Il TPS sostenuto è la tua velocità costante; il TPS di picco è il peggior secondo in cui devi sopravvivere senza che i codici arrivino in ritardo. Per l'OTP, il picco è ciò che conta: un codice di verifica che arriva quando l'utente ha rinunciato è un errore, anche se alla fine viene consegnato. Gli arrivi di OTP sono a raffiche e correlati: una campagna di marketing, una vendita lampo o un evento regionale nel GCC durante il Ramadan o una festività nazionale possono concentrare gli accessi in pochi minuti. Le dimensioni vincolano e riducono il TPS a quel picco con un margine di sicurezza, consentendo alla piattaforma condivisa di assorbire il sovraccarico tramite la coda anziché interromperlo.

È proprio in questo contesto che SMPP trae vantaggio in termini di costi operativi rispetto a HTTP. Un binding persistente elimina l'handshake TLS per ogni richiesta dal percorso critico, in modo che la latenza rimanga costante anche all'aumentare del volume, la caratteristica ideale in caso di picchi di traffico. I team che non necessitano di questo profilo spesso trovano più conveniente utilizzare l'API SMS tramite HTTPS; il compromesso è tra margine di throughput e stabilità della latenza a fronte della semplicità di integrazione.

Domande frequenti

Che cos'è TPS negli SMS?

TPS sta per transazioni al secondo: il numero di operazioni di invio SMS che la piattaforma accetta ogni secondo, ed è usato in modo intercambiabile con messaggi al secondo nella messaggistica A2P. In SMPP, una transazione corrisponde a una PDU submit_sm confermata da una submit_sm_resp. Il TPS conteggia gli invii accettati per la consegna, non i messaggi confermati su un dispositivo, che vengono tracciati separatamente tramite le ricevute di consegna che arrivano come PDU deliver_sm.

Quanti SMS al secondo può inviare SMPP?

Non esiste un numero universale; una singola connessione SMPP supporta un numero di messaggi pari a window ÷ RTT al secondo. Una finestra di 50 messaggi con un tempo di andata e ritorno di 80 ms produce circa 625 TPS per connessione, e l'esecuzione di più connessioni in parallelo aumenta ulteriormente questo valore, arrivando a migliaia. La velocità di trasmissione effettiva è quindi limitata dal TPS contrattualmente previsto e dal limite di velocità A2P di ciascun operatore di terminazione, a seconda di quale dei due sia inferiore.

Come si dimensionano i vincoli SMPP e la finestra per il carico di picco?

Parti dal tuo picco di TPS, non dalla media. Dividilo per il limite massimo per binding (finestra ÷ RTT) per ottenere il numero di binding, quindi assegna un TPS contrattuale sufficiente a coprire il picco con un margine di sicurezza. Conta i segmenti anziché i messaggi: i messaggi multipart e UCS-2 consumano transazioni aggiuntive e aggiungi un margine per i picchi di OTP. Modella la combinazione in un calcolatore di TPS prima di confermare, quindi esegui un test di carico.

Riferimenti

• Specifiche del protocollo SMPP v3.4: trasmissione asincrona, dimensione della finestra e semantica PDU: smpp.org
• Specifiche del protocollo SMPP v5.0 — stato di congestione e comportamento di limitazione della velocità: smpp.org
• GSMA — IR.71 Interconnessione rete-rete SMS e framework A2P: gsma.com
• BroadNet — Guida all'integrazione SMPP e Calcolatore TPS per il dimensionamento dei bind.