Come dimensionare TPS, code e capacità per i picchi di traffico SMS A2P
Guida operativa per calcolare i TPS, dimensionare le code, separare le priorità e testare la capacità di invio SMS A2P senza confondere accettazione, DLR e ricezione finale.
La domanda operativa: quanti TPS servono realmente a un'operazione SMS A2P
Dimensionare i TPS non significa scegliere un unico valore per l'intera piattaforma. La domanda utile è: quanti messaggi devono essere accettati, elaborati e inviati entro una specifica finestra operativa, per una determinata combinazione di destinazioni e classi di traffico?
I TPS richiesti devono derivare dal volume previsto e dalla finestra temporale obiettivo. Come punto di partenza: TPS base = messaggi previsti / secondi della finestra. Questa formula serve per pianificare e non costituisce una garanzia di capacità per un'API HTTP, una sessione SMPP, un provider, una rotta o una rete mobile.
Il valore risultante deve essere documentato insieme alle relative ipotesi: distribuzione temporale, mix di destinazioni, priorità del traffico, politica di ritento, scadenze e limiti confermati per ogni connessione o rotta. Senza queste ipotesi, un TPS aggregato può nascondere un collo di bottiglia rilevante.
- Definite cosa significa “entro la finestra”: accettazione interna, accettazione da parte del provider o stato finale comunicato.
- Calcolate per classe di traffico e per destinazione, non solo per il totale aggregato.
- Considerate il margine come una decisione esplicita per burst, ritenti e variazioni delle rotte, non come una garanzia implicita.
- Convalidate i limiti effettivi con il provider o l'operatore che gestisce ciascuna capacità.
Definire il picco: volume, finestra, distribuzione temporale e destinazioni
Il volume giornaliero o mensile non dimensiona un picco. Due operazioni con lo stesso volume possono richiedere capacità molto diverse se una distribuisce gli invii nell'arco di ore e l'altra deve inviarli in pochi minuti. L'unità di analisi deve essere il profilo temporale dell'evento, preferibilmente per minuto e, quando necessario, per secondo.
È inoltre importante separare le destinazioni. Un volume concentrato in un Paese, una rete, un intervallo di numerazione, un mittente o una rotta può raggiungere limiti prima del totale della piattaforma. I numeri di destinazione devono essere gestiti con una normalizzazione coerente con il piano internazionale E.164 e con le regole di instradamento applicabili all'integrazione.
I picchi di autenticazione sono spesso legati ad azioni simultanee degli utenti o a incidenti di accesso. Le campagne possono sincronizzarsi con un orario di lancio. Entrambi i casi richiedono un profilo di arrivo realistico, non una media giornaliera.
- Messaggi previsti per intervallo di tempo.
- Finestra obiettivo per classe di traffico.
- Distribuzione per Paese, rete, rotta e mittente.
- Percentuale prevista di OTP, traffico transazionale e campagne.
- Eventi che possono produrre burst: aperture, lanci, recupero dell'accesso o processi batch.
- Ritenti previsti e condizioni che li attivano.
Distinguere quattro limiti di capacità
Una risposta di accettazione dell'interfaccia non dimostra che il messaggio abbia completato il percorso fino al destinatario. Per operare con precisione, separate almeno quattro fasi: accettazione tramite API HTTP o SMPP, elaborazione e coda interne, accettazione o elaborazione da parte del provider e stato finale comunicato dalla catena SMS.
In SMPP, submit_sm e submit_sm_resp riflettono lo scambio tra l'ESME e l'SMSC. Il risultato successivo può essere comunicato tramite un SMSC Delivery Receipt quando richiesto. Pertanto, i TPS di submit_sm accettati non devono essere presentati come TPS consegnati né come prova di ricezione sul terminale.
Questa separazione migliora anche la diagnosi. Se l'accettazione locale resta stabile ma la coda interna cresce, il limite è prima dell'uscita. Se le richieste pendenti aumentano o le risposte peggiorano, il problema può trovarsi nella connessione o nell'estremità remota. Se lo stato finale cambia in base alla destinazione, l'analisi deve essere effettuata per rotta e rete, non solo come media globale.
- Limite di accettazione: richieste ammesse dall'interfaccia.
- Limite di elaborazione: capacità di convalidare, accodare, assegnare priorità e inoltrare.
- Limite del provider o della rotta: capacità tecnica e contrattuale confermata per ciascuna destinazione.
- Comportamento della rete: stati e tempi finali che possono variare lungo la catena di consegna.
Calcolo base dei TPS e margine documentato
Il calcolo iniziale è diretto: dividete il numero di messaggi da elaborare per i secondi disponibili. Per esempio, se un'operazione deve accettare e inoltrare un lotto entro una determinata finestra, il TPS base rappresenta il tasso medio minimo per tale finestra. Successivamente, confrontate quel tasso con il profilo temporale: se gli arrivi si concentrano all'inizio, il tasso di ingresso può superare ampiamente la media.
Il margine non deve essere scelto come valore universale. Deve rispondere a un'ipotesi concreta: un burst iniziale, il ripristino di una sessione, un aumento temporaneo delle richieste, una ridistribuzione delle destinazioni o ritenti controllati. È preferibile registrare vari scenari — previsto, elevato e di contingenza — piuttosto che nascondere tutti i rischi dietro un unico moltiplicatore.
Il calcolo deve essere ripetuto per ogni partizione operativa. Una piattaforma può disporre di capacità aggregata sufficiente e, nonostante ciò, non avere la capacità necessaria per una determinata destinazione o rotta.
- TPS base = messaggi previsti / secondi della finestra.
- Calcolate separatamente i TPS in entrata e in uscita.
- Aggiungete margine solo in presenza di una causa operativa identificata.
- Confrontate il risultato con i limiti per rotta, destinazione, connessione e classe di traffico.
- Rivedete il calcolo quando cambiano il profilo delle destinazioni, la finestra o la politica di ritento.
Perché la media inganna
Una media attenua proprio il comportamento che causa gli incidenti. Se migliaia di richieste arrivano contemporaneamente, un tasso medio giornaliero non spiega né la profondità di coda necessaria né l'anzianità che raggiungeranno i messaggi. Il progetto deve considerare la differenza tra il tasso di arrivo e il tasso di uscita sostenibile in ciascun intervallo.
Anche la concentrazione per destinazione conta. L'invio verso più destinazioni non equivale all'invio dello stesso volume verso un'unica rete. I limiti specifici non sono standardizzati da SMPP né da HTTP: devono essere conosciuti attraverso la documentazione applicabile, gli accordi operativi e l'osservazione della rotta reale.
Per gli OTP, inoltre, un'attesa prolungata può trasformare un messaggio tecnicamente elaborabile in un messaggio inutile. Per questo, un picco non si gestisce soltanto aumentando la coda: richiede di decidere quale traffico ammettere, quale ritardare e quale far scadere in modo controllato.
- Analizzate i massimi per secondo o per minuto, non solo le medie.
- Misurate la concentrazione per destinazione, rotta, mittente e tipo di traffico.
- Modellate l'arrivo iniziale delle campagne e degli eventi di autenticazione.
- Definite il punto oltre il quale ogni classe di messaggio perde utilità.
Dimensionare le code: profondità, anzianità e scadenza
La profondità di coda richiesta dipende dall'eccesso temporaneo del tasso di ingresso rispetto all'uscita sostenibile. Un'approssimazione operativa consiste nel calcolare il massimo accumulo della differenza tra tasso di arrivo e tasso di servizio durante il picco. Se entrano più messaggi di quanti ne possano uscire, il differenziale si accumula; quando l'uscita torna a superare l'ingresso, la coda si svuota.
La sola profondità non è sufficiente. Stabilite un'anzianità massima ammissibile per ogni classe di traffico. Una coda può contenere tutti i messaggi e continuare a non rispettare l'utilità di un OTP o di una notifica transazionale sensibile al tempo. L'anzianità deve essere misurata a partire da un timestamp definito e coerente, per esempio dall'accettazione della richiesta da parte della piattaforma.
SMPP consente di indicare un validity_period, che rappresenta un orario di scadenza nell'SMSC oltre il quale il messaggio deve essere scartato se non consegnato. Questa capacità non sostituisce una scadenza funzionale dell'applicazione: la piattaforma deve evitare che un messaggio privo di valore resti inutilmente nelle code interne o competa con il traffico critico.
- Calcolate il massimo accumulo previsto durante il picco.
- Stabilite un limite di anzianità per ciascuna classe di traffico.
- Definite cosa accade al superamento dell'anzianità: annullamento, scadenza o comunicazione al sistema mittente.
- Allineate la scadenza interna al validity_period e alle regole del provider, quando applicabile.
- Misurate profondità e anzianità per coda, destinazione e priorità.
Separare OTP, messaggi transazionali e campagne
OTP, traffico transazionale e campagne non dovrebbero condividere un'unica coda senza controlli. La classificazione è una decisione di prodotto e operativa, ma deve tradursi in politiche esplicite di ammissione, priorità, riserva di capacità, scadenza e degrado del servizio.
Gli OTP richiedono in genere un'anzianità funzionale molto breve. I messaggi transazionali possono avere una tolleranza diversa a seconda del processo aziendale. Le campagne legittime e basate sul consenso, invece, sono generalmente candidate a una pianificazione più flessibile quando la capacità è sotto pressione. La politica deve essere nota ai team di prodotto, operazioni e ai sistemi che originano i messaggi.
SMPP include priority_flag e campi correlati al servizio, ma lo standard non prescrive una politica di accodamento né garantisce che un contrassegno di priorità produca lo stesso risultato in tutte le implementazioni. La priorità deve essere applicata principalmente nella piattaforma stessa e coordinata con le condizioni della rotta.
- Riservate capacità o ammissione al traffico critico quando necessario.
- Evitate che una campagna consumi la coda o la capacità destinata agli OTP.
- Assegnate anzianità massima e azione di scadenza per classe.
- Registrate il motivo di ogni degrado per l'analisi successiva.
- Mantenete gli invii legittimi, basati sul consenso e soggetti alle regole applicabili.
Budget di latenza e semantica dei DLR
Un budget di latenza utile divide il percorso in fasi osservabili: tempo fino all'accettazione API o SMPP, attesa nella propria coda, tempo fino all'accettazione o all'elaborazione del provider e tempo fino allo stato finale comunicato. Ogni fase deve avere il proprio timestamp, la propria fonte e un metodo di correlazione.
Non equiparate la risposta iniziale alla ricezione finale. In SMPP, la risposta a submit_sm conferma lo scambio della richiesta con l'SMSC, mentre il risultato successivo viene comunicato tramite un delivery receipt quando richiesto. Gli stati possono includere, tra gli altri, DELIVRD, EXPIRED, UNDELIV e REJECTD.
Inoltre, non tutti i rapporti di consegna hanno la stessa semantica. Il 3GPP distingue i rapporti emessi dal Service Centre da quelli emessi dalla stazione mobile. Pertanto, un DLR emesso da un SMSC o da una rete intermedia deve essere etichettato in base al suo emittente e al suo significato. Non deve essere presentato automaticamente come prova indipendente della ricezione sul terminale.
- Misurate la latenza per fase, non solo come tempo totale.
- Usate i percentili per individuare code lunghe e degrado delle code.
- Conservate la fonte dello stato: piattaforma, provider, SMSC o altra parte della catena.
- Distinguete tra accettazione, stato finale comunicato e ricezione sul terminale quando esistono evidenze di tale natura.
- Evitate promesse di ricezione finale basate esclusivamente su una risposta iniziale o su un DLR con semantica non confermata.
Domande frequenti
Come si calcolano i TPS necessari per gli SMS A2P?
Come punto di partenza, dividete i messaggi previsti per i secondi della finestra obiettivo. Calcolate poi per destinazione, rotta, connessione e classe di traffico, documentando separatamente il margine per burst, ritenti e variazioni operative. Il risultato è un'esigenza di pianificazione, non una garanzia di capacità della rete.
Un submit_sm_resp riuscito significa che l'SMS è arrivato sul cellulare?
No. submit_sm_resp riflette la risposta alla richiesta SMPP tra ESME e SMSC. Il risultato successivo richiede l'osservazione del delivery receipt, quando richiesto, e l'analisi del suo stato e della sua semantica. Un DLR emesso da un SMSC non dimostra automaticamente la ricezione sul terminale.
Come si calcola la dimensione di una coda SMS?
Stimate il massimo accumulo durante gli intervalli in cui il tasso di arrivo supera il tasso di uscita sostenibile. Oltre alla profondità, definite un'anzianità massima per classe di traffico e l'azione da eseguire al suo superamento, come scadenza o annullamento controllato.
Perché devo separare OTP e campagne?
Perché i loro requisiti di utilità e attesa sono diversi. Una campagna può essere pianificata o ridotta in presenza di pressione sulla capacità, mentre un OTP tende a perdere valore se attende troppo. Le politiche devono separare ammissione, priorità, anzianità e degrado del servizio.
In che modo SMPP influisce sul dimensionamento della concorrenza?
SMPP consente richieste asincrone e usa sequence_number per correlare richieste e risposte. Un'approssimazione utile consiste nello stimare le richieste in volo come TPS obiettivo moltiplicati per la latenza osservata di submit_sm_resp. Il limite finale deve essere adeguato per sessione in base alla documentazione, agli errori, ai timeout e al comportamento osservato del provider.
Quale precauzione richiedono i ritenti HTTP?
Un timeout o una connessione chiusa prima di ricevere una risposta non dimostra che l'invio non sia stato accettato. Poiché un invio può non essere idempotente, i ritenti non devono essere automatizzati senza un identificatore di idempotenza, una verifica affidabile dello stato o un'evidenza equivalente che eviti duplicati.
Fonti consultate
- SMPP Protocol Specification v3.4, Issue 1.2SMPP Developers Forum
- RFC 9110: HTTP SemanticsInternet Engineering Task Force (IETF) / RFC Editor
- 3GPP TS 23.040: Technical realization of the Short Message Service (SMS)3rd Generation Partnership Project (3GPP)
- Recommendation ITU-T E.164: The international public telecommunication numbering planInternational Telecommunication Union (ITU)