e TPS (transactions par seconde) correspond au nombre d'envois de SMS effectués par votre plateforme chaque seconde. Sur un réseau SMPP, le débit soutenu est déterminé par la fenêtre de session (le nombre de PDU non acquittés en transit) divisée par la latence aller-retour vers le SMSC : débit ≈ fenêtre ÷ RTT. Pour dépasser la limite d'une session, exécutez plusieurs liaisons en parallèle.
Vous voulez un résultat chiffré sans vous soucier de la théorie ? Indiquez la taille de votre fenêtre, la latence et le nombre de liaisons dans le calculateur TPS et il vous fournira le débit par liaison et le débit total. Cet article explique le fonctionnement de cet outil.
Que signifie TPS dans les SMS ?
Le TPS (transactions par seconde), également appelé messages par seconde dans la messagerie A2P, mesure le nombre d'opérations d'envoi de messages quittant votre système et étant acceptées en aval chaque seconde. En termes SMPP, une transaction correspond à une PDU submit_sm que le SMSC accuse réception par une réponse submit_sm_resp. Le TPS étant l'unité de mesure de tous les contrats, limites de débit et plans de capacité, sa définition exacte est essentielle : il comptabilise les envois acceptés pour livraison, et non les messages confirmés livrés à un terminal – ce dernier faisant l'objet d'un flux distinct de confirmation de livraison (DLR) arrivant ultérieurement sous forme de PDU deliver_sm.
La plupart des erreurs de planification de capacité résident dans la distinction entre le débit d'envoi et le débit de livraison. Vous pouvez envoyer 5 000 TPS alors qu'un opérateur en aval ne traite qu'à 2 000 TPS ; l'écart ainsi créé alimente une file d'attente. Planifier le débit implique de planifier l'ensemble de la chaîne : votre client, la session SMPP vers la plateforme, le routage de la plateforme vers la passerelle SMSC de destination et le plafond de débit A2P de cet opérateur.
Comment fonctionne réellement le débit SMPP : fenêtre et latence
SMPP est un protocole TCP persistant et à état. Une seule liaison est établie, permettant l'échange bidirectionnel de PDU pendant plusieurs heures. Le débit d'une liaison unique ne dépend pas de la bande passante (les PDU SMS sont très petites), mais de deux variables : la fenêtre asynchrone et le temps d'aller-retour.
La fenêtre correspond au nombre maximal de PDU `submit_sm` que vous pouvez envoyer avant de devoir attendre une réponse `submit_sm_resp`. En mode synchrone, la fenêtre est en réalité de 1 : vous envoyez une requête, vous bloquez jusqu'à la réponse, puis vous envoyez une nouvelle requête ; un seul aller-retour, lent, suffit donc à saturer le système. En mode asynchrone (avec fenêtre), vous pouvez envoyer jusqu'à N requêtes sans blocage, et les réponses sont reçues simultanément. Ce N correspond à la taille de la fenêtre, négociée avec la plateforme à chaque liaison.
Étant donné qu'une liaison peut avoir au maximum `window` PDU en attente, et que chaque PDU occupe le canal pendant un temps d'aller-retour (RTT) avant que son emplacement ne se libère, le plafond d'une liaison unique est simplement la fenêtre divisée par le RTT :
# Plafond de débit SMPP pour une liaison unique tps_per_bind = taille_fenêtre / rtt_secondes # Fenêtre de 10 PDU non acquittées, 100 ms aller-retour vers le SMSC : tps_per_bind = 10 / 0,100 = 100 submit_sm/s # Même fenêtre, latence réduite de moitié à 50 ms : tps_per_bind = 10 / 0,050 = 200 submit_sm/s # Passage à l'échelle horizontale sur N liaisons parallèles : total_tps = tps_per_bind * n_binds = 200 * 4 = 800 submit_sm/sDeux leviers d'action découlent de cette situation. Élargir la fenêtre de traitement permet à davantage de PDU de transiter par aller-retour. Réduire le RTT (en plaçant le client près du point d'ingestion de la plateforme ou en supprimant les échanges TLS par requête, ce qu'offre précisément une liaison SMPP persistante par rapport à une requête HTTP par appel) accélère le recyclage de chaque créneau. Une fenêtre trop petite pénalise une liaison à faible latence ; une fenêtre trop grande se contente de mettre en mémoire tampon les PDU que le SMSC n'est pas prêt à traiter, augmentant ainsi la latence sans améliorer le débit.
Exemple fonctionnel : conversion de la fenêtre et du RTT en TPS, puis liaisons multiples
Supposons que votre client se trouve dans la même région que la plateforme et mesure un RTT de 80 ms en pleine charge. Avec une fenêtre négociée de 50 ms, une seule liaison permet de maintenir un débit de 50 ÷ 0,080 ≈ 625 TPS. Ce débit est déjà suffisant pour la plupart des expéditeurs. Lorsque votre pic de trafic nécessite davantage de ressources, vous n'auriez pas besoin d'augmenter sans cesse la fenêtre (au-delà d'un point où les requêtes seraient simplement mises en file d'attente), mais vous ajouteriez des liaisons. Quatre liaisons à 625 TPS chacune permettent d'atteindre un débit cumulé d'environ 2 500 TPS ; la plateforme répartit la charge des soumissions entre les sessions.
| Fenêtre (PDU non acquittés) | Durée du trajet aller-retour | TPS par liaison | Liaisons parallèles | TPS agrégé |
|---|---|---|---|---|
| 10 | 100 ms | 100 | 1 | 100 |
| 10 | 50 ms | 200 | 4 | 800 |
| 50 | 80 ms | 625 | 4 | 2 500 |
| 50 | 40 ms | 1 250 | 8 | 10 000 |
La dernière rangée (10 000 TPS) reste bien en deçà des 30 000 SMS/s qu’un seul nœud BroadNet soutient. Ce débit est atteint non pas grâce à une liaison unique et performante, mais grâce à une gestion optimisée, une faible latence et des liaisons horizontales. Modélisez votre propre configuration dans le calculateur de TPS avant de vous engager sur un débit contractuel, car les calculs déterminent le nombre de liaisons que votre équipe d'exploitation devra gérer et surveiller.
TPS provisionné par rapport à la capacité brute
Il existe deux valeurs de débit, et elles sont différentes. La capacité brute correspond au débit maximal que vos liaisons pourraient atteindre, calculé à partir de la fenêtre et de la latence. Le débit TPS provisionné (contractuel) est le débit auquel votre compte est autorisé à soumettre des données ; il s'agit d'une limite imposée par la plateforme afin d'éviter qu'un client ne sature une route partagée ou ne déclenche les contrôles d'abus d'un opérateur. Si votre contrat est de 500 TPS, l'ouverture de dix liaisons ne vous permettra pas d'atteindre 5 000 TPS ; la plateforme limite votre débit au niveau provisionné et renvoie des réponses de limitation (ESME_RTHROTTLED) au-delà.
Le dimensionnement des liaisons remplit deux fonctions : prévoir un débit contractuel suffisant pour votre pic de trafic réel, et configurer suffisamment de liaisons et de fenêtres de traitement pour atteindre ce débit, compte tenu de votre latence. Un sous-dimensionnement entraîne une limitation du débit ; un surdimensionnement des liaisons par rapport à un contrat insuffisant représente un gaspillage de ressources d'exploitation. Dimensionnez d'abord le contrat en fonction de la demande maximale, puis dimensionnez les liaisons pour l'atteindre.
Qu'est-ce qui réduit votre débit réel ?
La formule définit un plafond net. Quatre facteurs concrets font baisser le débit réel, et chaque plan de capacité doit en tenir compte :
- Segmentation. Un message plus long qu'un segment SMS est divisé et envoyé sous forme de plusieurs PDU submit_sm (message concaténé UDH). Un message marketing GSM-7 de 480 caractères est composé de trois segments et consomme donc trois transactions de votre budget TPS, au lieu d'une seule. L'UCS-2 (arabe, émojis) réduit la limite par segment à 70 caractères ; les campagnes non latines consomment donc plus rapidement les TPS. Lors de la planification, comptez les segments, et non les messages.
- Gestion des files d'attente et contre-pression. Lorsque vous soumettez des données plus rapidement que l'opérateur en aval ne les termine, les PDU sont mises en file d'attente. Une plateforme saine applique une contre-pression (limitation du débit des réponses ou réduction de la fenêtre d'exécution) plutôt que de les abandonner silencieusement. Considérez ESME_RTHROTTLED et l'augmentation de la latence de réponse comme des signaux incitant à ralentir la boucle de soumission, et non comme des erreurs nécessitant des tentatives de réessai systématiques.
- Limites de débit par route. L'opérateur de destination fixe son propre plafond de paquets par seconde (TPS) A2P par expéditeur ou par liaison, indépendamment de votre contrat. Vous pouvez envoyer jusqu'à 5 000 TPS, mais si le réseau de destination n'accepte que 1 000 TPS pour votre identifiant d'expéditeur, la livraison effective sera limitée à 1 000 TPS et les paquets restants seront mis en file d'attente. Ce sont souvent les plafonds au niveau de la route, et non votre liaison, qui déterminent le débit réel.
- Charge soutenue versus pic de charge. Une fenêtre dimensionnée pour une charge moyenne ne pourra pas absorber un pic. Le trafic OTP est par nature irrégulier — le lancement d'un produit ou une diffusion déclenche un afflux massif de codes de vérification en quelques secondes — il faut donc dimensionner la fenêtre pour le pic de charge, et non pour la moyenne quotidienne.
Pic versus persistance : dimensionnement des pics OTP
Le TPS soutenu correspond à votre débit constant ; le TPS de pointe représente la seconde critique à traverser sans que les codes n'arrivent en retard. Pour les OTP, c'est le pic qui importe : un code de vérification reçu après que l'utilisateur a abandonné est considéré comme un échec, même s'il est finalement délivré. Les arrivées d'OTP sont irrégulières et corrélées : une campagne marketing, une vente flash ou un événement régional dans les pays du Golfe, comme le Ramadan ou un jour férié, peuvent concentrer les connexions en quelques minutes. La taille du réseau limite et contracte le TPS à ce pic, avec une marge de sécurité, et permet à la plateforme partagée d'absorber le surplus grâce à la mise en file d'attente plutôt qu'à la suppression des requêtes.
C’est également là que le protocole SMPP justifie son coût opérationnel par rapport à HTTP. Une liaison persistante élimine l’établissement de liaison TLS pour chaque requête du chemin critique, ce qui permet de maintenir une latence stable malgré l’augmentation du volume de trafic – une caractéristique essentielle lors des pics de trafic. Les équipes qui n’ont pas besoin de ce profil de latence privilégient souvent l’API SMS via HTTPS ; le compromis réside dans la marge de manœuvre en termes de débit et de stabilité de la latence au détriment de la simplicité d’intégration.
Vous avez besoin de dimensionner votre bande passante pour une charge de travail à volume élevé ou à pics d'envoi de SMS ? Calculez votre fenêtre, votre latence et votre pic à l'aide du calculateur TPS, puis contactez-nous pour la mise en service. BroadNet prend en charge jusqu'à 30 000 SMS/seconde par nœud sur des routes vers 200+ pays (en direct avec l'opérateur dans 86 d'entre eux) via 1,000+ connexions d'opérateurs avec un SLA de plateforme de 99,99 %, sur SMPP ou l'API SMS.
Foire aux questions
Qu'est-ce que le TPS dans les SMS ?
Le TPS (transactions par seconde) correspond au nombre d'envois de SMS acceptés par votre plateforme chaque seconde. Ce terme est synonyme de « messages par seconde » dans la messagerie A2P. En SMPP, une transaction correspond à une unité de données de protocole (PDU) submit_sm accusée de réception par une réponse submit_sm_resp. Le TPS comptabilise les envois acceptés pour livraison, et non les messages confirmés sur un terminal, ces derniers étant suivis séparément par les accusés de réception (PDU deliver_sm).
Combien de SMS par seconde le protocole SMPP peut-il envoyer ?
Il n'existe pas de valeur universelle ; une liaison SMPP unique prend en charge un nombre de messages par seconde égal à la fenêtre ÷ RTT. Une fenêtre de 50 messages avec un aller-retour de 80 ms permet d'atteindre environ 625 TPS par liaison. L'exécution de plusieurs liaisons parallèles augmente considérablement ce débit, jusqu'à plusieurs milliers. Le débit réel est alors limité par le nombre de TPS contractuel et la limite de débit A2P de chaque opérateur de terminaison, la valeur la plus basse étant retenue.
Comment dimensionner les liaisons SMPP et la fenêtre de charge maximale ?
Partez de votre débit de transactions par seconde (TPS) maximal, et non de votre TPS moyen. Divisez-le par le plafond par liaison (fenêtre ÷ RTT) pour obtenir le nombre de liaisons, puis provisionnez un TPS contractuel pour couvrir le pic avec une marge de sécurité. Comptez les segments plutôt que les messages (les messages multiparties et UCS-2 consomment des transactions supplémentaires) et ajoutez une marge pour les pics de trafic OTP. Modélisez cette combinaison dans un calculateur de TPS avant de valider, puis effectuez un test de charge.
Références
- Spécification du protocole SMPP v3.4 — transmission asynchrone, taille de la fenêtre et sémantique des PDU : smpp.org
- Spécification du protocole SMPP v5.0 — état de congestion et comportement de limitation : smpp.org
- GSMA — IR.71 Cadre d'interconnexion de réseau à réseau SMS et A2P : gsma.com
- BroadNet — guide d'intégration SMPP et le calculateur TPS pour le dimensionnement des liaisons.