Как микробизнесу Беларуси провести нагрузочный тест SMPP

Нагрузочный тест SMPP показывает, где упрётся поток SMS в час пик: в лимит оператора, в пропускную способность шлюза или в размер отправляемого окна. Прогнать его стоит за две–четыре недели до сезонного всплеска, когда канал ещё можно спокойно перенастроить. Дальше — как посчитать TPS, очередь и запас, как провести тест своими силами и что смотреть в результатах, чтобы не получить дубли и потерянные DLR.

Почему тест «на глазок» не работает

Основная нагрузка на SMS-канал приходится на короткие интервалы. Не на сутки, не на месяц. Пик может длиться 20–30 минут: старт акции, рассылка по базе, напоминание об оплате в последний день. В эти минуты отправитель упирается в ограничения, которые в спокойном режиме незаметны.

Оператор принимает сообщения не бесконечно. У шлюза есть лимит на соединение, у аккаунта квота, у самого SMPP-соединения окно — столько сообщений можно отправить до подтверждения. Если пиковый поток выше этих границ, часть сообщений уходит в буфер, часть отклоняется с кодом ESME_RTHROTTLED, часть теряется на ретраях. Потери DLR выглядят как «отправлено», но статус так и не пришёл, и вы не знаете, дошло ли SMS.

Тест нужен, чтобы узнать свои границы до того, как в них упрётся живая рассылка. Ещё одна причина — форма потока. В реальном пике сообщения идут неровно, с паузами и всплесками, а транзакционные SMS с коротким текстом соседствуют с маркетинговыми на несколько сегментов. Кириллица в UCS-2 занимает больше места, чем латиница, и это тоже меняет нагрузку на канал.

Как посчитать TPS, очередь и запас на пик?

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

Очередь считают от разницы между поступающим потоком и тем, что канал успевает отдать. Если в пик система генерирует 50 сообщений в секунду, а шлюз стабильно пропускает 30, разница в 20 сообщений в секунду копится в буфере. За 15 минут пика это ощутимый объём, и он либо разойдётся после пика, либо выльется в отказы.

Запас не берут «примерно». Смотрите, за сколько минут очередь рассасывается после пика. Если дольше 10–15 минут, запаса мало: следующая волна придёт на уже забитый буфер.

Если сообщения копятся перед шлюзом, а не внутри него, поможет локальная очередь — отдельный буфер, который сглаживает всплеск и не даёт каналу захлебнуться. Как её настроить, разобрано в статье про локальную очередь перед SMPP-шлюзом.

Как прогнать нагрузочный тест: пошаговый план

1. Соберите baseline. Замерьте текущий рабочий поток: сколько сообщений в секунду уходит сейчас, сколько статусов возвращается, есть ли повторы. Без этой точки отсчёта результат теста не с чем сравнить.
2. Возьмите тестовый маршрут. Не гоняйте нагрузку по боевому трафику клиентов. Отдельный аккаунт или тестовый sender ID покажет картину, не задев живые рассылки.
3. Поднимите нагрузку ступенями. Начните с 10% от планового пика, подержите минуту-две, затем 25%, 50%, 75% и 100%. Ступени показывают, на каком уровне появляются первые отказы.
4. Смотрите на коды ошибок. ESME_RTHROTTLED означает, что вы упёрлись в лимит скорости. ESME_RMSGQFUL — переполнение очереди. Эти коды точнее любых графиков говорят, где узкое место.
5. Проверьте дубли. Отправьте один и тот же message_id дважды и убедитесь, что платформа распознаёт повтор. Тест без проверки дублей бессмысленен: именно на пике ретраи и плодят лишние SMS.
6. Замените DLR. Считайте, сколько deliver_sm пришло на отправленные submit_sm. Расхождение подскажет, что статусы теряются на нагрузке.
7. Проверьте keep-alive. Если соединение рвётся под нагрузкой, часть статусов не дойдёт до получателя. Контролируйте enquire_link и следите, чтобы разрывов не было.
8. Повторите тест после настройки. Любое изменение окна, квоты или очереди сдвигает показатели. Один прогон — ещё не результат.

Перед тестом полезно пройтись по списку проверок, чтобы не забыть базовые вещи. Подробный перечень собрали в материале про тестирование SMPP-шлюза перед подключением.

Как читать результаты и что менять

Хороший результат — ровная кривая без провалов, а отклик растёт линейно нагрузке. Плохой выглядит иначе: на очередной ступени TPS перестаёт расти, число отказов идёт вверх. Значит, канал выбрал свою ёмкость.

Если упёрлись в лимит скорости, вариантов два: согласовать квоту с провайдером или разнести поток между несколькими соединениями. Если переполняется очередь, увеличьте буфер и настройте приоритеты. Транзакционные SMS — коды подтверждения, статусы заказов — должны уходить раньше маркетинговых. Если теряются DLR, проверьте таймауты и обрыв соединений: при разрыве статусы приходят не всем сообщениям.

Часто корень проблемы лежит не в шлюзе, а в том, как система-источник отдаёт сообщения. Если заявки и клиенты живут в CRM, поток удобнее строить прямо оттуда. Как это сделать без разработки, описано в статье про подключение SMPP-шлюза к CRM.

Типичные ошибки при нагрузочном тесте

• Тестируют только средний TPS и не проверяют короткие пики. Реальная рассылка идёт волнами.
• Гоняют нагрузку по боевому трафику и портят метрики живым клиентам.
• Не проверяют дубли: после теста обнаруживают, что ретраи размножили SMS.
• Считают отправленные сообщения, а не полученные DLR. «Ушло» и «дошло» — разные вещи.
• Один раз прогоняют тест и успокаиваются, хотя после каждой настройки картина меняется.
• Оставляют нулевой запас: канал работает на пределе, и первое же превышение плана даёт отказы.