Пропускная способность SMS API: как рассчитать MPS и размер очереди

Средний объём почти ничего не говорит о требуемой мощности SMS-интеграции. Компания может отправлять 100 тысяч сообщений в день, но 40 тысяч из них должны уйти за первые десять минут после события. Если SMS API и workers рассчитаны только на суточное среднее, очередь будет разгружаться часами.

Пропускную способность удобно выражать в MPS — messages per second. Но расчёт должен учитывать запросы, получателей, сегменты, приоритеты и ограничение конкретного маршрута.

Начать со сценариев

Соберите по каждому типу сообщения:

• обычный и пиковый объём;
• длительность пика;
• допустимую задержку;
• TTL;
• среднее и максимальное число сегментов;
• приоритет;
• операторов и маршруты;
• ожидаемый рост;
• поведение при сбое.

OTP и массовая сервисная кампания могут иметь одинаковый объём, но совершенно разные требования. Первый сценарий чувствителен к секундам, второй иногда допускает растягивание на часы.

Базовый расчёт

Если нужно обработать N сообщений за T секунд, минимальная средняя скорость равна N / T. Для 60 000 сообщений за 20 минут: 60 000 / 1 200 = 50 MPS.

Это нижняя граница без запаса и без другого трафика. Если параллельно идут 10 MPS критичных уведомлений, требуется уже 60 MPS. Добавьте резерв на неравномерность, повторы и рост, но не завышайте его без измерений.

Сообщения, запросы и сегменты

Один HTTP-запрос может содержать пакет получателей, а одно длинное SMS — несколько тарифицируемых сегментов. Уточните, в каких единицах провайдер задаёт квоту. Возможны три разные величины:

• RPS — запросы в секунду;
• MPS — сообщения или получатели в секунду;
• SPS — SMS-сегменты в секунду.

Если среднее сообщение содержит 1,3 сегмента, поток 100 получателей в секунду создаёт около 130 сегментов в секунду. Для бюджета и некоторых маршрутов это принципиально. Причины сегментации разобраны в статье про длину SMS.

Закон Литтла для очереди

При устойчивом потоке примерный размер системы связан с интенсивностью и временем: L = λ × W. Если приходит 80 задач в секунду, а среднее время внутри конвейера 5 секунд, одновременно там находится около 400 задач.

Для аварийного backlog полезнее прямой расчёт. Если накопилось 120 000 сообщений, входящий поток остаётся 20 MPS, а система обрабатывает 100 MPS, чистая скорость разгрузки — 80 MPS. Очередь уйдёт примерно за 1 500 секунд, то есть 25 минут. Если processing rate равен входящему, backlog не уменьшится вообще.

Ограничение самого медленного звена

Итоговая скорость не выше минимума из:

• создания задач бизнес-системой;
• записи и чтения очереди;
• числа и скорости workers;
• клиентского rate limit;
• квоты SMS API;
• пропускной способности маршрута и оператора;
• скорости обработки DLR, если она влияет на downstream.

Ускорение workers не помогает, если провайдер разрешает 50 MPS. Повышение API-квоты бесполезно, если один worker синхронно ждёт каждый ответ.

Конкурентность

При среднем времени API-вызова 200 мс один последовательный worker теоретически выполняет около 5 запросов в секунду. Для 50 RPS потребуется примерно 10 параллельных операций плюс запас. Но пакетные запросы и асинхронный клиент меняют модель.

Не увеличивайте конкурентность бесконечно. Она повышает число открытых соединений, нагрузку на базу и риск резкого всплеска после восстановления. Общий лимитер должен контролировать суммарный поток всех экземпляров.

Резерв для критичного трафика

Если кампания занимает всю квоту, OTP попадёт в конец очереди. Зарезервируйте MPS для приоритетного класса и ограничьте скорость bulk-трафика. Схема приоритетов SMS должна быть частью расчёта мощности.

Резерв не обязан простаивать: weighted scheduler может временно отдавать свободную квоту другим классам, но быстро возвращать её при появлении критичных задач.

Сбой и восстановление

После получасовой недоступности накопится backlog. План мощности должен отвечать, за сколько он исчезнет после восстановления и какие сообщения уже просрочены. Сначала удаляются или закрываются задачи с истёкшим TTL, затем трафик разгружается с ограничением, чтобы не вызвать второй сбой.

Если резервный провайдер имеет меньшую квоту, RTO нужно считать по ней. Сам факт переключения маршрута ещё не означает сохранение времени доставки.

Нагрузочный тест

Формулы проверяются измерениями. Нагрузочное тестирование SMS должно отделять генерацию нагрузки от реальной отправки и использовать sandbox, mock или согласованный ограниченный контур.

Измеряйте throughput, p95/p99 latency, возраст очереди, CPU, соединения, ошибки, 429 и время восстановления после паузы. Тест ровным потоком не заменяет резкий пик и restart workers.

Планирование роста

Стройте несколько сценариев: обычный день, маркетинговый пик, аварийное оповещение и сбой провайдера. Указывайте допущения и дату данных. Пересматривайте расчёт после изменения шаблонов, потому что число сегментов влияет на стоимость и иногда на пропускную способность.

Алерт нужен до исчерпания мощности: прогноз времени разгрузки очереди полезнее сообщения «очередь уже переполнена».

Чек-лист

• пиковый объём известен по каждому сценарию;
• MPS не перепутан с RPS и сегментами;
• учтён параллельный критичный трафик;
• определено самое медленное звено;
• рассчитано время разгрузки backlog;
• просроченные задачи не отправляются после восстановления;
• квота общая для всех workers;
• формулы подтверждены нагрузочным тестом;
• есть запас и регулярный пересмотр прогноза.

Итог

Пропускная способность SMS API — это способность доставить нужный объём в допустимое время, а не максимальное число workers. Расчёт начинается с пиков и TTL, различает запросы, сообщения и сегменты, учитывает самое медленное звено и скорость восстановления. Тогда очередь становится управляемым буфером, а не местом, где уведомления незаметно стареют.