Сравнение производительности и нагрузочное тестирование chan_sip и pjsip

Введение

Технологии не стоят на месте и на смену нашему любимому chan_sip пришел его более навороченный братишка pjsip. Но везде ли уместно его использовать? Эффективнее ли он использует возможности «железа» наших серверов? В данной статье мы рассмотрим процесс нагрузочного тестирования с помощью связки sipp и htop и сравним результаты для chan_sip и pjsip. Будет собрано 2 стенда (для Asterisk версий 13 и 15), в каждом будет по 2 виртуальные машины с установленными на них voxlink Distro на базе CentOS 6.10 (c chan_sip) и FreePBX Distro на базе SangomaLinux 7.5 (c pjsip) в одной локальной сети. На всех виртуалках «железо» будет одинаковое:

• Процессор — Intel(R) Xeon(R) CPU E3-1226 v3 @ 3.30GHz
• Оперативная память – 1Gb ddr3 RAM
• Сеть – 1 Гбит/c

Так же стоит отметить, что на всех установленных дистрибутивах присутствует web-интерфейс FreePBX и необходимые нам утилиты sipp и htop.

Требования к тестированию и сборка стенда и начало тестов

Поскольку тестирование будет проводиться внутри локальной сети и на виртуальных машинах, результаты могут показаться несколько стерильными, но в достаточной мере будут демонстрировать отличия в производительности в работе протоколов без учета работы с диском (записи разговоров).

Итак, определим критерии отказа для нашего теста:

• CPU поднимается выше 60%
• «Проседания» в аудиопотоке в процессе звонка
• Менее 5 минут устойчивой производительности

Поясним, почему именно такие критерии. Начнем с нагрузки на CPU – тут все просто, в большинстве случаев сервер телефонии размещается на сервере, выполняющем множество других функций, будь то проксирование, контроль и анализ трафика и множество других, да и запас производительности всегда иметь не повредит. Далее стоит упомянуть что нас интересует «чистая» связь, без артефактов в течение некоторого времени, минимум пять минут, чтобы убедиться, что все в порядке, что и подводит нас к оставшимся двум критериям.

Как и говорилось выше сами звонки мы будем генерировать с помощью sipp – утилиты для генерации трафика по sip протоколу, включающей в себя сценарии работы как SIP-сервера (UAS) так и SIP-клиента (UAC). На момент написания статьи, установить sipp можно с помощью менеджера пакетов yum

#yum install -y sipp

Тесты без медиа для chan_sip и pjsip

Итак, виртуалки развернуты и запущены, прокидываем обычный сиповый транк для утилиты, добавляем простейший диалплан в /etc/asterisk/extensions_custom.conf и приступаем к тестированию. Диалплан выглядит так (для эхо-теста без медиа):

Транки для астерисков должны выглядеть примерно таким образом:

Начнем с chan_sip на Asterisk 13. Запускаем sipp указывая ей следующие параметры:

sipp 192.168.32.222 -s 101 -i 192.168.32.52 -d 300s -l 4000 -aa -mi 192.168.32.52 -rtp_echo -nd -r 20

• 192.168.32.222 – это ip станции на которую звоним
• -s 101 – номер на который звоним
• -i 192.168.32.52 – адрес АТС с которой звоним (там где запустили sipp, адрес источника сообщений)
• -d 300s – длительность звонка 5 минут (указано в секундах)
• -l 4000 – ограничение на 4000 одновременных звонков
• -aa – автоматические ответы ОК на UPDATE
• -mi 192.168.32.52 задаем локальный ip для rtp (в нашем случае АТС на которой запускаем sipp)
• -rtp_echo – запуск в режиме rtp-эха
• -nd – прерывание звонков при неправильных sip-сообщениях
• -r 20 -максимальное количество звонков в секунду (CPS)

В процессе тестирования меняем параметр -r, подставляя различные значения, и смотрим как ведет себя наша АТС.

Получаем вот такие результаты:

Эти же тесты теперь прогоним для станции использующей pjsip и получим следующие результаты:

Для виртуальных машин с Astrisk 15 проводим такие же тесты:

Итак, вывод: при работе с chan_sip в 13й и 15й версии мы получили примерно одинаковые результаты (около 40 звонков в секунду, если выше то начинается излишняя нагрузка на процессор и летят Warning’и) и они несколько ниже, чем при работе с pjsip (около 45-50 звонков в секунду, свыше так же загружается процессор). Теперь перейдем к тем же тестам, но уже с медиа.

Тесты с медиа для chan_sip и pjsip

Единственным отличием в исходных данных от предыдущих тестов будет разница в диалплане, теперь мы будем запускать в ответ медиа (проще всего для этого использовать music on hold).

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

Из полученных данных можно сделать вывод, что в этот раз chan_sip проявил себя куда лучше, нежели его продвинутая версия в лице pjsip. Результаты таковы:

Для астериска 13й версии: chan_sip – 4 CPS, pjsip – 2

Для астериска 15й версии: chan_sip — 3, pjsip – 2

Вывод

Исходя из полученных результатов тестирования, хотелось бы отметить, что не всегда использование pjsip будет оправданно, и в процессе работы с ним может сложиться ситуация, что мы сами задушим производительность своей системы.