Нагрузочное тестирование SMPP показывает, сколько сообщений в секунду выдерживает конкретное соединение, когда растёт очередь и как шлюз реагирует на ошибки. Для бизнеса в Беларуси этого достаточно, чтобы заранее найти узкое место перед массовой отправкой: в приложении, соединении, настройках SMPP или на стороне провайдера. Ниже приведён план проверки без догадок: подготовить стенд, провести несколько тестов, собрать ответы и определить безопасную скорость отправки.
Что именно проверяет нагрузочный тест SMPP?
Одна цифра «SMS в секунду» не описывает работу шлюза полностью. При тестировании проверяют скорость принятия сообщений, время ответа на submit_sm, рост очереди, разрывы bind-соединения и получение статусов доставки. Если приложение принимает запросы быстро, но очередь постоянно увеличивается, фактическая пропускная способность ниже скорости генерации сообщений.
Для малого бизнеса полезно разделить тест на четыре показателя:
- скорость отправки сообщений из приложения в SMPP-шлюз;
- доля успешных ответов и коды ошибок;
- задержка между отправкой и получением DLR;
- стабильность соединения при длительной работе.
Проверяйте каждый показатель отдельно. Например, DLR показывает результат обработки сообщения сетью, но не заменяет контроль ответа на сам запрос отправки. Для наблюдения за статусами пригодится материал о том, как настроить мониторинг SMPP через DLR.
Как подготовить безопасный стенд для проверки?
Тестовую отправку лучше отделить от рабочего потока. Создайте отдельную очередь, отдельный идентификатор отправителя и ограниченный набор номеров, которыми разрешено пользоваться для проверки. Если провайдер предлагает песочницу, сначала проведите тест там: в ней можно проверить DLR, ошибки и склейку длинных сообщений без запуска рабочей рассылки. Практическая инструкция по такому сценарию описана в статье о SMPP-песочнице для проверки SMS и DLR.
Перед запуском зафиксируйте исходные параметры:
- версию SMPP и настройки bind;
- число параллельных соединений;
- лимит сообщений в секунду, согласованный со шлюзом;
- размер сообщения и кодировку;
- таймаут ответа;
- правило повторной постановки сообщения в очередь.
Сравнивать результаты можно только при одинаковых условиях. SMS на кириллице и латинице может занимать разное количество частей, поэтому отдельно проверьте короткое сообщение и текст, который выходит за предел одного сегмента. Настройки кодировки и UCS-2 разобраны в материале о передаче кириллицы в SMPP.
Как провести тест на скорость без перегрузки шлюза?
Начните с небольшой скорости и постепенно увеличивайте её. На каждом уровне отправляйте одинаковую тестовую пачку и записывайте результат. Резкий старт на максимальном значении не показывает реальную производительность: он смешивает предел приложения, лимит соединения и реакцию шлюза на всплеск.
- Запустите отправку с одного соединения и небольшой скоростью.
- Проверьте, что приложение получает положительные ответы на запросы.
- Увеличьте скорость и повторите тест с тем же размером сообщения.
- После этого добавьте второе соединение, если такая схема разрешена настройками шлюза.
- Зафиксируйте значение, при котором очередь начинает расти или появляются ошибки.
На каждом шаге измеряйте не только среднюю скорость. Запишите минимальное, среднее и максимальное время ответа. Если среднее значение выглядит нормально, но отдельные запросы регулярно получают длинную задержку, массовая отправка всё равно может остановиться из-за таймаутов.
| Этап проверки | Что отправлять | Что фиксировать |
|---|---|---|
| Базовый | Короткое сообщение в одной части | Ответ шлюза и время ответа |
| Кодировка | Текст на русском языке | Ошибки кодировки и длину сообщения |
| Пиковый | Пачку с постепенно растущей скоростью | Очередь, таймауты и throttling |
| Длительный | Ровный поток в течение согласованного периода | Разрывы bind и стабильность DLR |
Как определить безопасную скорость для массовой отправки?
Рабочий лимит выбирают по результатам стабильного теста, а не по кратковременному пику. Если при определённой скорости очередь остаётся управляемой, ответы приходят без таймаутов, а соединение не разрывается, это значение можно использовать как исходное. Затем оставляют запас для колебаний трафика и повторов.
Отдельно обработайте ошибку Throttling. В документации Devino указано: после такой ошибки сообщение нужно вернуть в очередь и выдержать таймаут на этом соединении в одну секунду (Devino Documentation). Значит, обработчик не должен немедленно повторять запрос в том же потоке. Иначе приложение само создаст новый всплеск и увеличит очередь.
Удобная схема выглядит так: успешные сообщения покидают очередь, временные ошибки возвращаются с задержкой, постоянные ошибки попадают в отдельный журнал. Для автоматической обработки кодов и DLR можно использовать чек-лист о том, как обрабатывать ошибки SMPP и статусы доставки.
| Сигнал во время теста | Вероятная причина | Действие |
|---|---|---|
| Растёт очередь | Приложение отправляет быстрее допустимого лимита | Снизить скорость и добавить контроль очереди |
| Появляется throttling | Превышен лимит шлюза или соединения | Поставить сообщение в очередь и выдержать задержку |
| Растёт число таймаутов | Слишком короткий таймаут или перегружен канал | Проверить сеть, соединения и время ответа |
| Разрывается bind | Сбой сети или неверная логика keepalive | Проверить Enquire Link и восстановление соединения |
| DLR приходит с задержкой | Проблема обработки статусов или внешний участок маршрута | Разделить время ответа шлюза и время доставки |
Какие ошибки чаще всего искажают результат?
- Тестируют только один короткий всплеск. Он показывает пиковую реакцию, но не стабильность очереди.
- Смешивают отправку и DLR в одном показателе. Ответ SMPP и статус доставки приходят на разных этапах.
- Не записывают коды ошибок. Без них невозможно отличить лимит скорости от проблем авторизации или формата сообщения.
- Повторяют ошибку сразу. Для throttling нужен контролируемый возврат в очередь и задержка.
- Проверяют только один bind. При нескольких соединениях меняется распределение нагрузки.
- Используют рабочую базу номеров без согласования. Для стенда нужен заранее определённый тестовый набор.
После теста сохраните журнал с временем отправки, идентификатором сообщения, ответом SMPP, кодом ошибки и временем получения DLR. В нём должна быть видна граница: на какой скорости очередь ещё сокращается, а после какого значения начинает расти. Для подключения большого объёма трафика через SMPP можно отдельно проверить параметры версии 3.4 и поддерживаемые типы сообщений: такая возможность описана в справочных материалах по SMPP API.
3 шага, которые можно сделать на этой неделе:
- Собрать тестовый стенд с отдельной очередью и журналом всех ответов.
- Провести ступенчатый тест для короткого сообщения и текста на кириллице.
- Зафиксировать рабочий лимит, правила обработки throttling и порядок восстановления bind.
