Планирование пропускной способности SMS и количества отправленных сообщений в секунду: расчет параметров SMPP-привязок для кампаний с большим объемом рассылок.

TPS (транзакций в секунду) — это количество операций отправки SMS, которые ваша платформа выполняет каждую секунду. В сети SMPP устойчивая пропускная способность определяется окном сессии — количеством неподтвержденных PDU в процессе передачи — деленным на задержку в пути до SMSC: пропускная способность ≈ окно ÷ RTT. Для масштабирования за пределы лимита одной сессии используйте несколько параллельных привязок.

Что означает TPS в SMS

TPS — транзакции в секунду (используется как синоним сообщений в секунду в A2P-сообщениях) — измеряет, сколько операций отправки сообщений покидают вашу систему и принимаются нижестоящими участниками каждую секунду. В терминах SMPP одна транзакция — это один PDU submit_sm, который SMSC подтверждает с помощью submit_sm_resp. TPS — это единица измерения, в которой написаны все контракты, ограничения скорости и планы пропускной способности, поэтому точное определение имеет значение: он учитывает отправленные сообщения, принятые к доставке, а не сообщения, подтвержденные к доставке на мобильное устройство — это отдельный поток доставки-получения (DLR), который поступает позже в виде PDU deliver_sm.

Различие между скоростью отправки и скоростью доставки — вот где в большинстве случаев возникают ошибки при планировании пропускной способности. Вы можете отправлять данные со скоростью 5000 транзакций в секунду, в то время как оператор, работающий с нижестоящими системами, завершает соединение только при 2000; этот разрыв заполняет очередь где-то. Планирование пропускной способности означает планирование всей цепочки — вашего клиента, SMPP сессии с платформой, маршрута платформы к конечному SMSC-шлюзу и собственного потолка скорости A2P этого оператора.

Как на самом деле работает пропускная способность SMPP: окно и задержка.

SMPP — это протокол TCP с постоянным сохранением состояния. Вы устанавливаете соединение один раз и передаете PDU в обоих направлениях в течение нескольких часов. Пропускная способность при одном соединении определяется не пропускной способностью — SMS PDU очень малы — а двумя переменными: асинхронным окном и временем кругового пути.

Окно — это максимальное количество PDU-пакетов submit_sm, которые вы можете отправить, прежде чем вам придется ждать ответа submit_sm_resp. В синхронном режиме окно фактически равно 1: вы отправляете запрос, блокируете выполнение до получения ответа, затем отправляете запрос снова — таким образом, один медленный цикл отправки ограничивает все процессы. В асинхронном (оконном) режиме вы отправляете до N запросов без блокировки, и ответы поступают одновременно. Это N — размер окна, согласовываемый с платформой для каждого привязки.

Поскольку в рамках одной привязки может быть не более "оконных" блоков распределения питания (PDU), и каждый блок PDU занимает канал в течение одного времени кругового пути (RTT), прежде чем его слот освободится, потолок для одной привязки — это просто окно, разделенное на RTT:

1# Максимальный предел пропускной способности SMPP для одной привязки
2tps_per_bind = window_size / rtt_seconds
3 
4# Окно из 10 неподтвержденных PDU, время кругового пути до SMSC 100 мс:
5tps_per_bind = 10 / 0.100 = 100 submit_sm/s
6 
7# То же окно, задержка уменьшена вдвое до 50 мс:
8tps_per_bind = 10 / 0.050 = 200 submit_sm/s
9 
10# Горизонтальное масштабирование по N параллельным привязкам:
11total_tps = tps_per_bind * n_binds
12 
13= 200 * 4 = 800 submit_sm/s

Из этого вытекают два варианта. Расширение окна приведет к увеличению количества PDU, находящихся в процессе передачи за один цикл. Сокращение RTT — путем размещения клиента рядом с точкой приема платформы или путем удаления рукопожатий TLS для каждого запроса, что в точности соответствует преимуществам постоянного SMPP-соединения по сравнению с HTTP-запросом для каждого вызова — позволит ускорить перезапуск каждого слота. Слишком маленькое окно ограничивает доступ к каналу с низкой задержкой; слишком большое окно просто буферизует PDU, к которым SMSC еще не готов, и увеличивает задержку без увеличения пропускной способности.

Пример работы: окно и RTT к TPS, затем несколько привязок.

Предположим, ваш клиент находится в том же регионе, что и платформа, и измеряет время отклика (RTT) 80 мс под нагрузкой. При согласованном окне в 50 Мбит/с один цикл привязки обеспечивает скорость 50 ÷ 0,080 ≈ 625 транзакций в секунду (TPS). Этого уже достаточно для большинства отправителей. Когда пиковая нагрузка увеличивается, вы не пытаетесь увеличить окно — после определенного момента оно просто ставится в очередь — вы добавляете циклы привязки. Четыре цикла привязки по 625 TPS каждый дают примерно 2500 TPS в сумме; платформа распределяет нагрузку между сессиями.

Нижний ряд находится вблизи установленного BroadNet лимита скорости до 30 000 SMS/сек на узел — он достигается не за счет одного героического переключения, а за счет небольшого временного окна, низкой задержки и горизонтальных переключений. Перед тем как заключать договор, смоделируйте свою собственную комбинацию в калькуляторе TPS, поскольку именно арифметические вычисления определяют, сколько переключений вашей команде операторов придется выполнить и отслеживать.

Заданное количество TPS по сравнению с исходными возможностями

Существует два показателя пропускной способности, и они не одинаковы. «Необработанная пропускная способность» — это то, что, согласно приведенным выше расчетам с учетом окна и задержки, могут обеспечить ваши привязки. «Зарезервированные (контрактные) TPS» — это скорость, с которой ваш аккаунт имеет право отправлять данные — лимит, установленный платформой, чтобы один клиент не мог «заблокировать» общий маршрут или активировать средства контроля злоупотреблений оператора. Если ваш контракт предусматривает 500 TPS, открытие десяти широких привязок не позволит вам достичь 5000; платформа ограничивает вас до зарезервированного значения и возвращает ответы о регулировании (ESME_RTHROTTLED) выше него.

Таким образом, определение размера привязки выполняет две задачи: выделение достаточного количества контрактных TPS для вашей реальной пиковой нагрузки и настройка достаточного количества привязок и окон для фактического достижения этого выделенного числа с учетом вашей задержки. Недостаточное выделение ресурсов приведет к ограничению скорости; избыточное создание привязок при низком контрактном значении приведет к пустой трате усилий операционного персонала. Сначала определите размер контракта в соответствии с пиковой нагрузкой, а затем определите размер привязок, чтобы достичь ее.

Что снижает вашу реальную пропускную способность?

Формула позволяет установить четкий верхний предел. Четыре реальных фактора снижают объем поставляемой продукции ниже этого предела, и каждый план развития мощностей должен учитывать их:

• Сегментация. Сообщение, длиннее одного SMS-сегмента, разделяется и отправляется как несколько PDU submit_sm — объединенное (UDH) сообщение. Маркетинговое сообщение GSM-7 длиной 480 символов состоит из трех сегментов, поэтому оно расходует три транзакции из вашего бюджета TPS, а не одну. UCS-2 (арабский язык, эмодзи) снижает лимит на один сегмент до 70 символов, поэтому кампании, не использующие латинский язык, расходуют TPS быстрее. При планировании учитывайте сегменты, а не сообщения.
• Очереди и обратное давление. Когда вы отправляете данные быстрее, чем оператор завершает обработку, PDU ставятся в очередь. Здоровая платформа применяет обратное давление — регулируя скорость ответов или уменьшая эффективное окно — вместо того, чтобы незаметно отбрасывать данные. Рассматривайте ESME_RTHROTTLED и растущую задержку ответа как сигналы для замедления цикла отправки, а не как ошибки, которые следует игнорировать и повторять попытку.
• Ограничения скорости для каждого оператора маршрута. Оператор конечного узла устанавливает собственное ограничение количества транзакций A2P (TPS) для каждого отправителя или для каждого соединения, независимо от вашего контракта. Вы можете отправлять 5000 транзакций в секунду, но если сеть назначения принимает 1000 для вашего идентификатора отправителя, реальная скорость доставки будет ограничена 1000, а остальные попадут в очередь. Реальная пропускная способность часто определяется ограничениями на уровне маршрута, а не вашего соединения.
• Устойчивый трафик против пикового. Размер окна, рассчитанного на среднюю нагрузку, не поглотит пик. Трафик OTP по своей природе является пиковым — запуск продукта или трансляция запускает поток кодов подтверждения за считанные секунды — поэтому размер окна должен соответствовать пиковому значению, а не среднесуточному.

Пиковый и устойчивый: определение оптимального размера дозы для всплесков OTP.

Постоянный показатель TPS — это стабильный темп работы; пиковый показатель TPS — это худший момент, который вам необходимо пережить, не дожидаясь задержки доставки кодов. Для OTP пиковый показатель имеет значение — код подтверждения, который приходит после того, как пользователь уже сдался, даже если в итоге он доставлен. Поступление OTP происходит импульсно и коррелирует: маркетинговая кампания, распродажа или региональное мероприятие в странах Персидского залива во время Рамадана или национального праздника могут сконцентрировать входы в систему в течение нескольких минут. Размер платформы определяет и регулирует показатель TPS в соответствии с пиковым значением с запасом, позволяя общей платформе поглощать избыток за счет постановки в очередь, а не отбрасывания.

Именно здесь SMPP оправдывает свою операционную стоимость по сравнению с HTTP. Постоянное подключение исключает рукопожатие TLS для каждого запроса из критического пути, поэтому задержка остается стабильной по мере роста объема — свойство, которое вам нужно при пиковом увеличении. Командам, которым не нужен такой профиль, часто лучше использовать SMS API вместо HTTPS; компромисс заключается в запасе пропускной способности и стабильности задержки по сравнению с простотой интеграции.

Часто задаваемые вопросы

Что такое TPS в SMS?

TPS означает транзакции в секунду — количество операций отправки SMS, принимаемых вашей платформой каждую секунду; в A2P-мессенджерах это число используется как синоним слова «сообщения в секунду». В SMPP одна транзакция — это один PDU submit_sm, подтвержденный submit_sm_resp. TPS учитывает отправленные для доставки сообщения, а не сообщения, подтвержденные на мобильном устройстве, что отслеживается отдельно по отчётам о доставке, поступающим в виде PDU deliver_sm.

Сколько SMS-сообщений в секунду может отправлять SMPP?

Универсального значения не существует; одна операция привязки SMPP поддерживает количество сообщений в секунду, равное значению окна ÷ RTT. Окно в 50 сообщений за 80 мс обеспечивает около 625 сообщений в секунду на одну операцию привязки, а запуск нескольких параллельных операций привязки позволяет увеличить пропускную способность до тысяч сообщений в секунду. Реальная пропускная способность затем ограничивается оговоренным в контракте количеством сообщений в секунду и собственным лимитом скорости A2P каждого оператора, в зависимости от того, какой из них меньше.

Как определить размер параметров привязки и окна SMPP для пиковой нагрузки?

Начните с пикового значения TPS, а не со среднего. Разделите его на максимальное значение на одно привязочное соединение (окно ÷ RTT), чтобы получить количество привязок, затем выделите контрактное количество TPS для покрытия пикового значения с запасом. Считайте сегменты, а не сообщения — многокомпонентные сообщения и сообщения UCS-2 потребляют дополнительные транзакции — и добавьте запас на всплески OTP. Смоделируйте комбинацию в калькуляторе TPS перед подтверждением, а затем проведите нагрузочное тестирование.

Ссылки

• Спецификация протокола SMPP v3.4 — асинхронная передача, размер окна и семантика PDU: smpp.org
• Спецификация протокола SMPP v5.0 — состояние перегрузки и поведение регулирования: smpp.org
• GSMA — IR.71 Взаимодействие между сетями SMS и структура A2P: gsma.com
• BroadNet — руководство по интеграции SMPP и калькулятор TPS для определения размера привязки.