Comment dimensionner les TPS, les files d’attente et la capacité pour les pics de trafic SMS A2P
Guide opérationnel pour calculer les TPS, dimensionner les files d’attente, séparer les priorités et tester la capacité d’envoi de SMS A2P sans confondre acceptation, DLR et réception finale.
La question opérationnelle : de combien de TPS une opération SMS A2P a-t-elle réellement besoin ?
Dimensionner les TPS ne consiste pas à choisir un chiffre unique pour toute la plateforme. La question utile est la suivante : combien de messages doivent être acceptés, traités et envoyés au cours d’une fenêtre opérationnelle donnée, pour une combinaison précise de destinations et de catégories de trafic ?
Les TPS requis doivent être déduits du volume prévu et de la fenêtre cible. Comme point de départ : TPS de base = messages prévus / secondes de la fenêtre. Cette formule sert à la planification ; elle ne constitue pas une garantie de capacité pour une API HTTP, une session SMPP, un fournisseur, une route ou un réseau mobile.
Le chiffre obtenu doit être documenté avec ses hypothèses : répartition temporelle, combinaison de destinations, priorité du trafic, politique de reprise, expirations et limites confirmées pour chaque connexion ou route. Sans ces hypothèses, un TPS agrégé peut masquer un goulot d’étranglement important.
- Définissez ce que signifie « dans la fenêtre » : acceptation interne, acceptation par le fournisseur ou état final communiqué.
- Calculez par catégorie de trafic et par destination, et pas seulement pour le total agrégé.
- Traitez la marge comme une décision explicite pour les rafales, les reprises et les variations de route, et non comme une garantie implicite.
- Validez les limites effectives auprès du fournisseur ou de l’opérateur qui gère chaque capacité.
Définir le pic : volume, fenêtre, répartition temporelle et destinations
Le volume quotidien ou mensuel ne permet pas de dimensionner un pic. Deux opérations ayant le même volume peuvent nécessiter des capacités très différentes si l’une répartit les envois sur plusieurs heures et l’autre doit les émettre en quelques minutes. L’unité d’analyse doit être le profil temporel de l’événement, de préférence par minute et, lorsque le cas l’exige, par seconde.
Il est également important de séparer les destinations. Un volume concentré sur un pays, un réseau, une plage de numérotation, un expéditeur ou une route peut atteindre des limites avant le total de la plateforme. Les numéros de destination doivent être gérés avec une normalisation cohérente avec le plan international E.164 et les règles de routage applicables à l’intégration.
Les pics d’authentification sont souvent liés à des actions simultanées des utilisateurs ou à des incidents d’accès. Les campagnes peuvent être synchronisées sur une heure de lancement. Dans les deux cas, un profil d’arrivée réaliste est nécessaire, et non une moyenne quotidienne.
- Messages prévus par intervalle de temps.
- Fenêtre cible par catégorie de trafic.
- Répartition par pays, réseau, route et expéditeur.
- Pourcentage attendu d’OTP, de trafic transactionnel et de campagnes.
- Événements pouvant produire des rafales : ouvertures, lancements, récupération d’accès ou traitements par lots.
- Reprises prévues et conditions qui les déclenchent.
Distinguer quatre limites de capacité
Une réponse d’acceptation de l’interface ne démontre pas que le message a achevé son parcours jusqu’au destinataire. Pour opérer avec précision, séparez au moins quatre étapes : l’acceptation par API HTTP ou SMPP, le traitement et la mise en file internes, l’acceptation ou le traitement par le fournisseur, et l’état final communiqué par la chaîne SMS.
En SMPP, submit_sm et submit_sm_resp reflètent l’échange entre l’ESME et le SMSC. Le résultat ultérieur peut être communiqué par un SMSC Delivery Receipt lorsqu’il a été demandé. Les TPS de submit_sm acceptés ne doivent donc pas être présentés comme des TPS délivrés ni comme une preuve de réception sur le terminal.
Cette séparation améliore aussi le diagnostic. Si l’acceptation locale reste stable mais que la file interne augmente, la limite se situe avant la sortie. Si les demandes en attente augmentent ou que les réponses se dégradent, le problème peut se situer dans la connexion ou à l’extrémité distante. Si l’état final varie selon la destination, l’analyse doit être effectuée par route et par réseau, et pas seulement selon une moyenne globale.
- Limite d’acceptation : requêtes admises par l’interface.
- Limite de traitement : capacité à valider, mettre en file, prioriser et acheminer.
- Limite du fournisseur ou de la route : capacité technique et contractuelle confirmée pour chaque destination.
- Comportement du réseau : états et délais finaux pouvant varier selon la chaîne de livraison.
Calcul de base des TPS et marge documentée
Le calcul initial est simple : divisez le nombre de messages qui doivent être traités par les secondes disponibles. Par exemple, si une opération doit accepter et acheminer un lot dans une fenêtre donnée, les TPS de base représentent le débit moyen minimal nécessaire pour cette fenêtre. Comparez ensuite ce débit au profil temporel : si les arrivées sont concentrées au début, le débit entrant peut largement dépasser la moyenne.
La marge ne doit pas être choisie comme un chiffre universel. Elle doit répondre à une hypothèse concrète : une rafale initiale, une reprise de session, une hausse temporaire des requêtes, une redistribution des destinations ou des reprises contrôlées. Il est préférable de consigner plusieurs scénarios — attendu, élevé et de secours — plutôt que de masquer tous les risques derrière un multiplicateur unique.
Le calcul doit être répété pour chaque partition opérationnelle. Une plateforme peut disposer d’une capacité agrégée suffisante tout en ne disposant pas de la capacité nécessaire pour une destination ou une route donnée.
- TPS de base = messages prévus / secondes de la fenêtre.
- Calculez séparément les TPS entrants et les TPS sortants.
- N’ajoutez une marge que lorsqu’une cause opérationnelle est identifiée.
- Comparez le résultat aux limites par route, destination, connexion et catégorie de trafic.
- Révisez le calcul lorsque le profil des destinations, la fenêtre ou la politique de reprise évolue.
Pourquoi la moyenne est trompeuse
Une moyenne lisse précisément le comportement qui provoque les incidents. Si des milliers de requêtes arrivent en même temps, un débit moyen quotidien n’explique ni la profondeur de file nécessaire ni l’ancienneté que les messages atteindront. La conception doit prendre en compte l’écart entre le débit d’arrivée et le débit de sortie soutenable à chaque intervalle.
La concentration par destination compte également. L’envoi vers plusieurs destinations n’équivaut pas à l’envoi du même volume vers un seul réseau. Les limites précises ne sont pas normalisées par SMPP ni par HTTP : elles doivent être connues grâce à la documentation applicable, aux accords opérationnels et à l’observation de la route réelle.
Pour les OTP, une attente prolongée peut en outre transformer un message techniquement traitable en message inutile. Un pic ne se gère donc pas seulement en augmentant la file d’attente : il faut décider quel trafic est admis, lequel est retardé et lequel doit expirer de façon contrôlée.
- Analysez les maxima par seconde ou par minute, et pas uniquement les moyennes.
- Mesurez la concentration par destination, route, expéditeur et type de trafic.
- Modélisez l’arrivée initiale des campagnes et des événements d’authentification.
- Définissez le point à partir duquel chaque catégorie de message perd son utilité.
Dimensionner les files d’attente : profondeur, ancienneté et expiration
La profondeur de file requise dépend de l’excédent temporaire du débit entrant sur le débit de sortie soutenable. Une approche opérationnelle consiste à calculer l’accumulation maximale de l’écart entre le débit d’arrivée et le débit de service pendant le pic. Lorsque davantage de messages entrent qu’il ne peut en sortir, l’écart s’accumule ; lorsque la sortie dépasse à nouveau l’entrée, la file se résorbe.
La profondeur seule ne suffit pas. Définissez une ancienneté maximale acceptable par catégorie de trafic. Une file peut contenir tous les messages tout en ne respectant plus l’utilité d’un OTP ou d’une notification transactionnelle sensible au temps. L’ancienneté doit être mesurée à partir d’un horodatage défini et cohérent, par exemple à compter de l’acceptation de la requête par la plateforme.
SMPP permet d’indiquer un validity_period, qui représente une heure d’expiration dans le SMSC au-delà de laquelle le message doit être supprimé s’il n’a pas été délivré. Cette capacité ne remplace pas une expiration fonctionnelle propre à l’application : la plateforme doit éviter qu’un message sans valeur reste inutilement dans les files internes ou entre en concurrence avec du trafic critique.
- Calculez l’accumulation maximale prévue pendant le pic.
- Établissez une limite d’ancienneté pour chaque catégorie de trafic.
- Définissez ce qui se produit lorsque l’ancienneté est dépassée : annulation, expiration ou information du système émetteur.
- Alignez l’expiration interne sur le validity_period et sur les règles du fournisseur lorsque cela s’applique.
- Mesurez la profondeur et l’ancienneté par file, destination et priorité.
Séparer les OTP, les messages transactionnels et les campagnes
Les OTP, le trafic transactionnel et les campagnes ne devraient pas partager une seule file sans contrôles. La classification relève d’une décision produit et opérationnelle, mais elle doit se traduire par des politiques explicites d’admission, de priorité, de réservation de capacité, d’expiration et de dégradation.
Les OTP nécessitent généralement une ancienneté fonctionnelle très courte. Les messages transactionnels peuvent avoir une tolérance différente selon le processus métier. À l’inverse, les campagnes légitimes et consenties sont généralement candidates à une programmation plus flexible lorsque la capacité est sous tension. La politique doit être connue des équipes produit, opérationnelles et des systèmes à l’origine des messages.
SMPP inclut priority_flag et des champs liés au service, mais la norme ne prescrit pas de politique de mise en file et ne garantit pas qu’un marquage de priorité produise le même résultat dans toutes les implémentations. La priorité doit principalement être appliquée au sein de la plateforme elle-même et coordonnée avec les conditions de la route.
- Réservez de la capacité ou de l’admission pour le trafic critique lorsque nécessaire.
- Évitez qu’une campagne consomme la file ou la capacité destinée aux OTP.
- Attribuez une ancienneté maximale et une action d’expiration par catégorie.
- Consignez la raison de chaque dégradation pour analyse ultérieure.
- Maintenez des envois légitimes, consentis et soumis aux règles applicables.
Budgets de latence et sémantique des DLR
Un budget de latence utile divise le parcours en étapes observables : délai jusqu’à l’acceptation par API ou SMPP, attente dans la file propre, délai jusqu’à l’acceptation ou au traitement par le fournisseur, et délai jusqu’à l’état final communiqué. Chaque étape doit avoir son horodatage, sa source et sa méthode de corrélation.
N’assimilez pas la réponse initiale à la réception finale. En SMPP, la réponse à submit_sm confirme l’échange de la requête avec le SMSC, tandis que le résultat ultérieur est communiqué par un delivery receipt lorsqu’il est demandé. Les états peuvent notamment inclure DELIVRD, EXPIRED, UNDELIV et REJECTD.
Tous les rapports de livraison n’ont pas non plus la même sémantique. La 3GPP distingue les rapports émis par le Service Centre de ceux émis par la station mobile. Par conséquent, un DLR émis par un SMSC ou un réseau intermédiaire doit être étiqueté selon son émetteur et sa signification. Il ne doit pas être présenté automatiquement comme une preuve indépendante de réception sur le terminal.
- Mesurez la latence par étape, et pas seulement sous la forme d’un délai total.
- Utilisez des percentiles pour identifier les files longues et la dégradation de la file.
- Conservez la source de l’état : plateforme, fournisseur, SMSC ou autre partie de la chaîne.
- Distinguez l’acceptation, l’état final communiqué et la réception sur le terminal lorsqu’il existe des preuves de cette nature.
- Évitez les promesses de réception finale fondées uniquement sur une réponse initiale ou sur un DLR dont la sémantique n’est pas confirmée.
Questions fréquentes
Comment calculer les TPS nécessaires pour les SMS A2P ?
Comme point de départ, divisez les messages prévus par les secondes de la fenêtre cible. Calculez ensuite par destination, route, connexion et catégorie de trafic, puis documentez séparément la marge pour les rafales, les reprises et les variations opérationnelles. Le résultat est un besoin de planification, et non une garantie de capacité réseau.
Un submit_sm_resp réussi signifie-t-il que le SMS est arrivé sur le mobile ?
Non. submit_sm_resp reflète la réponse à la requête SMPP entre l’ESME et le SMSC. Le résultat ultérieur nécessite d’observer le delivery receipt lorsqu’il a été demandé et d’analyser son état et sa sémantique. Un DLR émis par un SMSC ne démontre pas automatiquement la réception sur le terminal.
Comment calculer la taille d’une file SMS ?
Estimez l’accumulation maximale durant les intervalles où le débit d’arrivée dépasse le débit de sortie soutenable. En plus de la profondeur, définissez une ancienneté maximale par catégorie de trafic et l’action à effectuer lorsqu’elle est dépassée, telle qu’une expiration ou une annulation contrôlée.
Pourquoi séparer les OTP et les campagnes ?
Parce que leurs exigences d’utilité et d’attente sont différentes. Une campagne peut être planifiée ou réduite lorsque la capacité est sous pression, tandis qu’un OTP perd généralement sa valeur s’il attend trop longtemps. Les politiques doivent séparer l’admission, la priorité, l’ancienneté et la dégradation.
Comment SMPP influence-t-il le dimensionnement de la concurrence ?
SMPP permet des requêtes asynchrones et utilise sequence_number pour corréler les requêtes et les réponses. Une approche utile consiste à estimer les requêtes en cours comme les TPS cibles multipliés par la latence observée de submit_sm_resp. La limite finale doit être ajustée par session selon la documentation, les erreurs, les délais d’attente et le comportement observé du fournisseur.
Quelle précaution faut-il prendre avec les reprises HTTP ?
Un délai d’attente ou une connexion fermée avant la réception d’une réponse ne démontre pas que l’envoi n’a pas été accepté. Puisqu’un envoi peut ne pas être idempotent, les reprises ne doivent pas être automatisées sans identifiant d’idempotence, requête fiable de statut ou preuve équivalente permettant d’éviter les doublons.
Sources consultées
- 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)