# Planificación del rendimiento de SMS y TPS: dimensionamiento de los recursos de SMPP para campañas de alto volumen > El rendimiento de SMS por segundo (TPS) se rige por el tamaño de la ventana SMPP dividido por la latencia de ida y vuelta. A continuación, se explica cómo dimensionar las vinculaciones, planificar los picos de OTP y las campañas, y lograr un rendimiento óptimo. - URL canónica: https://www.broadnet.me/es/blog/sms-throughput-tps-smpp-bind-sizing - Idioma: es - Última actualización: 2026-10-20 - Editor: BroadNet (https://www.broadnet.me) - Publicado: 2026-08-03 - Autor: BroadNet Engineering TPS (transacciones por segundo) es la cantidad de operaciones de envío de SMS que su plataforma completa cada segundo. En SMPP, el rendimiento sostenido está determinado por la ventana de sesión (el número de PDU no confirmadas en tránsito) dividida por la latencia de ida y vuelta al SMSC: rendimiento ≈ ventana ÷ RTT. Para superar el límite de una sesión, ejecute múltiples enlaces en paralelo. > ¿Quieres el dato sin la teoría? Introduce el tamaño de tu ventana, la latencia y el número de enlaces en la [calculadora TPS](https://www.broadnet.me/tools/tps-calculator) y te devolverá el rendimiento por enlace y el rendimiento total. Este artículo explica el funcionamiento de la herramienta. ## Qué significa TPS en SMS TPS (transacciones por segundo, término que se usa indistintamente con mensajes por segundo en la mensajería A2P) mide cuántas operaciones de envío de mensajes salen del sistema y se aceptan en la red cada segundo. En términos de SMPP, una transacción es una PDU submit_sm que el SMSC confirma con una respuesta submit_sm_resp. TPS es la unidad en la que se escriben todos los contratos, límites de velocidad y planes de capacidad, por lo que es importante tener una definición precisa: cuenta los envíos aceptados para entrega, no los mensajes confirmados como entregados a un terminal; ese es un flujo de entrega-recibo (DLR) independiente que llega más tarde como PDU deliver_sm. La distinción entre la tasa de envío y la tasa de entrega es donde la mayoría de los planes de capacidad fallan. Se puede enviar a 5000 TPS mientras que un operador descendente solo procesa a 2000; la diferencia se acumula en alguna cola. Planificar el rendimiento implica planificar toda la cadena: el cliente, la sesión [SMPP](https://www.broadnet.me/developers/smpp) con la plataforma, la ruta de la plataforma hacia la pasarela [SMSC](https://www.broadnet.me/operators/smsc-gateway) de destino y el límite de velocidad A2P de dicho operador. ## Cómo funciona realmente el rendimiento de SMPP: ventana y latencia SMPP es un protocolo TCP persistente y con estado. Se establece una conexión una sola vez y se transmiten PDU en ambas direcciones durante horas. El rendimiento en una sola conexión no está determinado por el ancho de banda (las PDU de SMS son muy pequeñas), sino por dos variables: la ventana asíncrona y el tiempo de ida y vuelta. La ventana es el número máximo de PDU submit_sm que puede enviar antes de tener que esperar a que llegue una respuesta submit_sm_resp. En modo síncrono, la ventana es efectivamente 1: usted envía, se bloquea hasta obtener la respuesta y luego vuelve a enviar; por lo tanto, un viaje de ida y vuelta lento ralentiza todo. En modo asíncrono (con ventana), puede enviar hasta N envíos sin bloqueo, y las respuestas fluyen simultáneamente. Esa N es el tamaño de la ventana, que se negocia con la plataforma en cada enlace. Debido a que un enlace puede tener como máximo `window` PDU pendientes, y cada PDU ocupa el canal durante un tiempo de ida y vuelta (RTT) antes de que se libere su ranura, el techo de enlace único es simplemente la ventana dividida por el RTT: ``` # Límite de rendimiento SMPP para una sola vinculación tps_por_vinculación = tamaño_de_la_ventana / rtt_segundos # Ventana de 10 PDU no confirmadas, 100 ms de ida y vuelta al SMSC: tps_por_vinculación = 10 / 0,100 = 100 submit_sm/s # Misma ventana, latencia reducida a la mitad (50 ms): tps_por_vinculación = 10 / 0,050 = 200 submit_sm/s # Escalado horizontal para N vinculaciones paralelas: tps_total = tps_por_vinculación * n_vinculaciones = 200 * 4 = 800 submit_sm/s ``` De esto se derivan dos factores. Si se amplía la ventana, se generan más PDU en tránsito por cada viaje de ida y vuelta. Si se reduce el RTT (tiempo de ida y vuelta), ya sea colocando el cliente cerca del punto de ingesta de la plataforma o eliminando los protocolos de enlace TLS por solicitud (que es precisamente lo que ofrece un enlace SMPP persistente frente a una solicitud HTTP por llamada), cada ranura se recicla más rápido. Una ventana demasiado pequeña limita el acceso a un enlace de baja latencia; una ventana demasiado grande simplemente almacena en búfer las PDU que el SMSC no está preparado para procesar, lo que aumenta la latencia sin incrementar el rendimiento. ## Ejemplo práctico: ventana y RTT a TPS, luego múltiples enlaces Supongamos que su cliente se encuentra en la misma región que la plataforma y mide un RTT de 80 ms bajo carga. Con una ventana negociada de 50, un solo enlace mantiene 50 ÷ 0,080 ≈ 625 TPS. Esto ya es suficiente para la mayoría de los remitentes. Cuando su pico requiere más, no busca una ventana cada vez mayor (más allá de un punto en el que solo se pone en cola), sino que agrega enlaces. Cuatro enlaces de 625 TPS cada uno dan aproximadamente 2500 TPS agregados; la plataforma equilibra la carga de envíos entre las sesiones. | Ventana (PDU no confirmadas) | Tiempo de ida y vuelta | TPS por enlace | Enlaces paralelos | TPS agregado | |---|---|---|---|---| | 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 última fila (10.000 TPS) queda holgadamente dentro de los hasta 30.000 SMS/seg que sostiene un solo nodo de BroadNet, alcanzados no con una única conexión heroica, sino con una ventana de tiempo moderada, baja latencia y conexiones horizontales. Modela tu propia combinación en la [calculadora TPS](https://www.broadnet.me/tools/tps-calculator) antes de contratar una tarifa, ya que los cálculos determinan cuántas conexiones debe ejecutar y supervisar tu equipo de operaciones. ## TPS aprovisionado frente a capacidad bruta Hay dos cifras de rendimiento y no son iguales. La capacidad bruta es lo que los cálculos de ventana y latencia anteriores indican que sus enlaces podrían enviar. El TPS aprovisionado (contratado) es la tasa a la que su cuenta está autorizada a enviar; es un límite de política que la plataforma aplica para que un cliente no sature una ruta compartida ni active los controles de abuso de un operador. Si su contrato es de 500 TPS, abrir enlaces de diez anchos no le permitirá alcanzar los 5000; la plataforma le limita a la cifra aprovisionada y devuelve respuestas de limitación (ESME_RTHROTTLED) por encima de ella. Por lo tanto, el dimensionamiento de enlaces tiene dos funciones: proporcionar suficientes TPS contratados para el pico real y configurar suficientes enlaces y ventanas para alcanzar ese número aprovisionado, considerando la latencia. Si se aprovisionan menos de lo necesario, se producirá una limitación; si se configuran demasiados enlaces para un contrato bajo, se desperdiciarán recursos operativos. Primero, dimensione el contrato según la demanda máxima y luego ajuste los enlaces para alcanzarla. ## ¿Qué reduce tu rendimiento real? La fórmula proporciona un límite superior claro. Cuatro factores del mundo real hacen que el rendimiento entregado sea inferior a ese límite, y todo plan de capacidad debe tenerlos en cuenta: - Segmentación. Un mensaje de más de un segmento SMS se divide y se envía como varias PDU submit_sm (mensajes UDH concatenados). Un mensaje de marketing GSM-7 de 480 caracteres consta de tres segmentos, por lo que consume tres transacciones de su presupuesto de TPS, no una. UCS-2 (árabe, emoji) reduce el límite de un solo segmento a 70 caracteres, por lo que las campañas que no utilizan idiomas latinos consumen TPS más rápidamente. Al planificar, cuente los segmentos, no los mensajes. - Colas y contrapresión. Cuando se envía una solicitud más rápido de lo que un operador posterior la finaliza, las PDU se ponen en cola. Una plataforma en buen estado aplica contrapresión (limitando las respuestas o reduciendo la ventana de tiempo efectiva) en lugar de descartarlas silenciosamente. Considere ESME_RTHROTTLED y el aumento de la latencia de respuesta como señales para ralentizar el ciclo de envío, no como errores que deban reintentarse sin más. - Límites de velocidad del operador por ruta. El operador de destino establece su propio límite de TPS A2P por remitente o por enlace, independientemente de su contrato. Puede enviar a 5000 TPS, pero si la red de destino acepta 1000 para su ID de remitente, la entrega real se realiza a 1000 y el resto se pone en cola. Los límites a nivel de ruta, no su enlace, suelen definir el rendimiento real. - Carga sostenida frente a carga máxima. Una ventana dimensionada para la carga promedio no absorberá un pico. El tráfico OTP es inherentemente irregular: el lanzamiento de un producto o una transmisión genera una avalancha de códigos de verificación en segundos; por lo tanto, dimensione la ventana para el pico, no para el promedio diario. ## Pico versus sostenido: dimensionamiento para ráfagas de OTP El TPS sostenido es tu tasa constante; el TPS pico es el peor segundo que debes sobrevivir sin que los códigos lleguen tarde. Para OTP, el pico es lo que importa: un código de verificación que llega después de que el usuario se ha dado por vencido ha fallado, incluso si finalmente se entrega. Las llegadas de OTP son intermitentes y están correlacionadas: una campaña de marketing, una venta relámpago o un evento regional en el CCG durante el Ramadán o un día festivo nacional pueden concentrar los inicios de sesión en unos pocos minutos. El tamaño limita y contrae el TPS a ese pico con margen de seguridad, y permite que la plataforma compartida absorba el exceso mediante la gestión de colas en lugar de descartarlo. Aquí es donde SMPP justifica su coste operativo frente a HTTP. Un enlace persistente elimina el protocolo de enlace TLS por solicitud de la ruta crítica, por lo que la latencia se mantiene constante a medida que aumenta el volumen, la propiedad deseada ante picos de tráfico. Los equipos que no necesitan este perfil suelen beneficiarse más de la API de SMS (/products/sms-api) a través de HTTPS; la contrapartida es la capacidad de procesamiento y la estabilidad de la latencia frente a la simplicidad de la integración. > ¿El dimensionamiento es un problema para una carga de trabajo de alto volumen o con picos de OTP? Calcule su ventana, latencia y pico con la [calculadora de TPS](https://www.broadnet.me/tools/tps-calculator) y luego contáctenos para su aprovisionamiento. BroadNet admite hasta 30.000 SMS/seg por nodo a través de rutas a 200+ países (directo al operador en 86 de ellos) mediante 1,000+ conexiones de operadores con un SLA de plataforma del 99,99 %, en [SMPP](https://www.broadnet.me/developers/smpp) o la [API de SMS](https://www.broadnet.me/products/sms-api). ## Preguntas frecuentes ### ¿Qué es TPS en SMS? TPS significa transacciones por segundo: la cantidad de operaciones de envío de SMS que su plataforma acepta cada segundo, y se usa indistintamente con mensajes por segundo en la mensajería A2P. En SMPP, una transacción es una PDU submit_sm confirmada por una respuesta submit_sm_resp. TPS contabiliza los envíos aceptados para entrega, no los mensajes confirmados en un terminal, que se rastrean por separado mediante confirmaciones de entrega que llegan como PDU deliver_sm. ### ¿Cuántos SMS por segundo puede enviar SMPP? No existe un número universal; una única conexión SMPP admite una ventana multiplicada por el tiempo de ida y vuelta (RTT) de los mensajes por segundo. Una ventana de 50 mensajes durante un viaje de ida y vuelta de 80 ms produce aproximadamente 625 TPS por conexión, y al ejecutar varias conexiones en paralelo, esta cifra aumenta aún más, llegando a miles. El rendimiento real está limitado por el TPS contratado y el límite de velocidad A2P de cada operador de terminación, prevaleciendo el menor de estos. ### ¿Cómo dimensiono los enlaces SMPP y la ventana para la carga máxima? Empiece por su TPS máximo, no por el promedio. Divídalo por el límite por enlace (ventana ÷ RTT) para obtener el número de enlaces y, a continuación, asigne un TPS contratado para cubrir el pico con margen de seguridad. Cuente segmentos en lugar de mensajes (los mensajes multipartes y UCS-2 consumen transacciones adicionales) y añada margen para ráfagas de OTP. Modele la combinación en una calculadora de TPS antes de confirmarla y, a continuación, realice una prueba de carga. ## Referencias - Especificación del protocolo SMPP v3.4: transmisión asíncrona, tamaño de ventana y semántica de PDU: [smpp.org](https://smpp.org/) - Especificación del protocolo SMPP v5.0: estado de congestión y comportamiento de limitación de velocidad: [smpp.org](https://smpp.org/) - GSMA — IR.71 Interconexión de red a red SMS y marco A2P: [gsma.com](https://www.gsma.com/) - BroadNet — [Guía de integración SMPP](https://www.broadnet.me/developers/smpp) y la [Calculadora TPS](https://www.broadnet.me/tools/tps-calculator) para dimensionar los enlaces.