Тестирование Тrixbox 300 - Производительность Asterisk

Обратился клиент (небольшой интернет провайдер) с просьбой подсказать/предложить решение для телефонизации по SIP нескольких тысяч абонентов. Так как у клиента уже установлена АТС М200, СОРМ и биллинг, то необходимо простое преобразование SIP в 4E1. Однако необходимо выяснить, сможет ли Тrixbox 300 обработать 120 одновременных разговоров и 1500 SIP абонентов (коэффициент использования линий для городских абонентов около 12).

Стенд для тестирования

Фото: Стенд для тестирования Trixbox 300

Для тестирования был собран стенд из трех серверов Trixbox 300 и одного коммутатора, в испытуемом сервере установлены 2 платы Openvox D210P. Каждый сервер представляет собой промышленную платформу со следующими характеристиками:

 - CPU Intel Pentium 4 2.4 GHz
 - Chipset Intel 845GV ICH4
 - Front Side Bus 533 MHz
 - DDR-SDRAM 333 MHz 512 Mb

На каждом сервере установлен дистрибутив Trixbox 2.6.

Выходы потоковых плат попарно замкнуты друг на друга и поделены на две группы: одна для исходящих звонков, другая - для входящих. Исходящие вызовы одной платы являются входящими для другой. Два других сервера имитируют абонентов, по 500 на каждом.

 Схема стенда тестирования Trixbox 300
Рис.1 Схема стенда тестирования Trixbox 300

Сервер X инициирует звонки с помощью скрипта call-gen.php, имитируя 500 зарегистрированных абонентов с номерами от 1000 до 1499. Время перерегистрации - 1 час. Скрипт запускается с помощью crond каждую минуту и создает в заданных диапазонах случайное количество call файлов в которых инициируются звонки на случайные номера сервера Y через сервер Z. Длительность звонка варьируется от 1 до 5 минут. После соединения сервер Х проигрывает в канал музыку в формате alaw.

Пример call файла:

Channel: SIP/1696/91029 
Callerid: 1696 
MaxRetries: 8 
RetryTime: 227 
WaitTime: 126	 
Context: call-gen 
Extension: s 
Priority: 1 
Set: maxtime=283

фрагмент диал-план:

;для ограничения длительности вызова заворачиваем 
;вызов через локальный канал с опцией L 
;в ${maxtime} содержится таймаут 
[call-gen] 
exten => s,1,dial(LOCAL/s@timeout,20,L(${MATH(1000*${maxtime})})) 
;второе плечо: воспроизводим музыку  [[timeout] 
exten => s,1,answer() 
exten => s,2,musiconhold(default) 
exten => s,3,hangup

Сервер Y также иммитирует 500 абонентов с номерами от 1500 по 2000, время перерегистрации - 1 час. Все входящие вызовы направляются в контекст для проигрывания музыки, которая представляет собой музыкальный фрагмент, повторяющийся через 3 секунды:

[from-Z] 
exten => s,1,answer 
exten => s,2,musiconhold(test) 
exten => _.,1,answer 
exten => _.,2,musiconhold(test)  

Программа для замера/записи параметров Linux и Asterisk Запись параметров системы происходила с помощью скрипта-web страницы syswatch.php, который каждые 5 секунд считывал через интерфейс астериска AMI текущее количество звонков, текущее количество SIP сессий, загрузку процессора, среднюю загрузку процессора, состояние памяти и файла подкачки, а также позволяет выставить пользователю субъективную величину качества звука по пятибалльной шкале. В процессе прослушивания исходного сигнала при обнаружении акустических искажений оператор отмечает это при помощи radio-button и нажимает на кнопку snd_err! в нижней части. Всего имеется 5 уровней оценки сигнала:

10: сигнал без искажений;
20: незначительные искажения (выпадение одного - двух пакетов);
30: искажения, пропадания голоса длительностью до 1 секунды;
40: частые потери голоса в течении 5 секунд;
50: речь трудно различима более 5 секунд подряд.

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

Загрузка сервера по звонкам в режиме Trixbox в течении часа

Первоначально оценка качества звука производилась прослушиванием какого либо текущего звонка (команда chanspy), а так же простым прослушиванием музыки на удержании с самого сервера (команда musiconhold, формат mp3). К сожалению, когда были выполнены все основные тесты, выяснилось, что оба сервера (X и Z) генерируют moh с искажениями, а реальный звонок через сервер Z намного искажался на порядок меньше. Возможно это связано с тем, что Asterisk дает меньший приоритет воспроизведению музыки или функции прослушивания канала (при ее использовании замечались пропадания пакетов даже при отсутствии загрузки), а также с тем, что у сервера, инициирующего вызовы (Z) не хватало ресурсов  воспроизводить одновременно 60 файлов (при использовании mp3 значение  LA доходило до 10, после замены на alaw - до 5). В последствии производилось тестирование с использованием двух софтфонов: Kapanga, которым звонили на SJphone и воспроизводили музыку, по искажениям которой и проводили оценку.

Тестирование системы происходило в двух разных режимах. Это обусловлено тем, что в процессе обработки вызова диалплан FreePBX и исполняет несколько AGI скриптов (например, dialparties.agi). Накладные расходы на порождение отдельного процесса интерпретатора PHP усугубляются большим количеством вызовов: при средней длительности звонка в 5 минут и 60 одновременных звонках, ежеминутно генерировалось до 40..80 новых звонков (см. график справа).

Из-за большой разницы в производительности тестирование производилось в двух разных режимах: в режиме "Trixbox" и в режиме "преобразователя" (шлюза) из SIP в E1 и обратно.

Тестирование в режиме шлюза E1<=>SIP

В этом режиме осуществляется минимальная обработка вызова, все поступившие от абонентов сервер X) SIP звонки прямиком отправляются в поток:

[from-internal] 
;исходящие вызовы направляем в поток 
exten => _9XXXX,1,Dial(ZAP/g1/${EXTEN:1}) 
;для оценки потерь и качества голоса используем прослушивание и MOH 
exten => 555,1,chanspy() 
exten => 444,1,musiconhold()

Исходящие звонки с одной платы автоматически являются входящими для другой платы, они попадают в контекст:

[from-net] 
exten => _XXXX,1,Dial(SIP/${EXTEN},60,tTr)

а оттуда - происходит вызов абонента (в нашем случае - сервер Y).

Тестирование в режиме Trixbox

В этом режиме осуществляется обработка вызова в обычном диалплане freepbx, как и в первом случае, все поступившие от абонентов звонки отправляются в поток, но через функции диал-план freepbx:

[from-internal] 
;исходящие вызовы направляем в диалплан Freepbx 
include => from-internal-xfer 
include => bad-number  
;для оценки потерь и качества голоса используем прослушивание и MOH 
exten => 555,1,chanspy() 
exten => 444,1,musiconhold()

Исходящие звонки с одной платы автоматически являются входящими для другой платы, они попадают в контекст:

[from-net] 
exten => _XXXX,1,Dial(LOCAL/${EXTEN}@from-internal,60,tTr)

а оттуда - происходит вызов абонента через функции диал-план freepbx.

Итоги тестирования: режим Trixbox, E1<=>SIP

Для тестирования в этом режиме первоначально создали нагрузку в 50..60 звонков, сервера X и Y, имитируя абонентов, перерегистрировались каждые 600 секунд. Результаты тестирования записывались в таблицу, по которой строилась диаграмма для определения зависимости качества голоса от нагрузки на сервер:

Основные параметры системы при уменьшении количества одновременных звонков с 60 до 30
 Рис.2 Основные параметры системы при уменьшении количества одновременных звонков с 60 до 30

На графике по вертикальной оси отражено изменение нескольких величин:
curr_calls: Текущее количество звонков в системе (show channels)
sip_calls: Количество SIP звонков (sip show channels, коэфф 0.1)
cpu_idle: Загрузка процессора (коэфф. 0,5)
load_avg: Средняя загрузка (коэфф. 10)
snd_err: Искажения голоса
mem_t_free: Свободно памяти, кбайт (коэфф. 0,00001)
mem_t_used: Занято памяти, кбайт (коэфф. 0,00001)
swap_free: Свободно своп, кбайт (коэфф. 0,00001)
swap_used: Занято своп, кбайт (коэфф. 0,00001)

Для наглядности, на отдельной оси (серого цвета) расположены следующие величины:
call_diff: Относительное изменение количества звонков (коэфф. 0.5).

По горизонтальной оси расположены отсчеты. Время между отсчетами - 5 секунд.

По графику хорошо видно, что качество голоса растет пропорционально уменьшению величины load_avg (участки 0..43; 67..85). Однако поведение самой этой величины не укладывается ни в какие рамки: она может беспричинно расти и уменьшаться. Не понятно и поведение sip_calls: максимальное количество sip транзакций приходится на минимальное значение curr_calls. Более того, sip_calls растет и становится более неравномерным, приближается по форме к синусоиде (участок 157..187).

Так же хорошо заметна закономерность появления искажений и образования новых звонков. Например, на участке 19..25 call_diff растет на 4 пункта, а snd_err подскакивает с 10 до 30 (искажения, пропадания голоса длительностью до 1 секунды). То же самое заметно на участках 31..37, 43..49 и тд. Учитывая, что между измерениями 5 секунд, то максимальная практическая производительность сервера при использовании диал-план и обработок FreePBX не более 1..3 cps (звонков в секунду) с учетом текущей нагрузки в 50..60 вызовов. Такая низкая величина обусловлена активным использованием AGI.

Еще один график, на этот раз с малой загрузкой:

Загрузка Trixbox 300 при малом количестве вызовов
Рис.3 Загрузка Trixbox 300 при малом количестве вызовов

При этих измерениях для оценки качества звука производился звонок с софтфона на софтфон, качество голоса было отличным, потерь пакетов практически не было.

После первых тестов выяснилось, что сильное влияние на загрузку оказывает время перерегистрации абонентов. При таймауте  600 секунд, в течении минуты происходит перерегистрация около сотни абонентов, а использование для имитирования других серверов Asterisk порождает "волны" регистраций. Также замечено, что при установившемся количестве звонков (и отсутствия потока новых) качество голоса остается хорошим даже при 90..100 одновременных вызовов. Как только начинаются новые вызовы, так сразу начинают выпадать пакеты. Это можно объяснить накладными расходами на порождение новых процессов при вызове AGI скриптов.

Для уменьшения влияния SIP транзакций на производительность системы, время перерегистрации было увеличено до одного часа (3600 секунд). Также был отключен механизм qualify, который пингует каждую минуту все зарегистрированные телефоны пакетами OPTIONS, что также создает дополнительную нагрузку.

Загрузка Trixbox с отключеным qualify
Рис. 4 Загрузка Trixbox с отключеным qualify

На рис. 4 видно, что sip_calls более-менее коррелирует с другими параметрами системы, однако при замере образовалось слишком много звонков сразу (9 звонков в за отсчет, 5 cps), поэтому сильно подскочило значение load_avg.

Trixbox 300 оправдал свое название, его можно использовать для телефонизации трехсот абонентов при условиях: не более трех новых звонков в секунду, не более 60 одновременных вызовов без транскодинга. На практике такие значения достигаются при количестве абонентов 200-250 (у трети из них - кодеки со сжатием) при использовании подключения к ТФОП потоком Е1. В самые нагруженные часы несколько ухудшается качество музыки на ожидании, голос все же ходит без искажений. Если поток новых звонков невелик, то сервер может выдержать гораздо больше одновременных вызовов, вплоть до 120.

Итоги тестирования: режим шлюза, E1<=>SIP

В процессе тестирования необходимо было выяснить, сможет ли сервер Trixbox 300 заменить шлюз доступа Cisco AS5350 и предоставить возможность телефонизировать 1000 абонентов с помощью VoIP. Для этого сервер должен быть способен обработать 120 одновременных вызовов из SIP в Е1. При этом не требуется никакой обработки вызова.

В процессе тестирования нагрузку плавно увеличили с 0 до 120 одновременных звонков, время перерегистрации - 600 секунд, замер качества голоса осуществлялся прослушиванием канала (chanspy), кодек остался без изменений (G.711):

Тест Trixbox в режиме преобразователя SIP<->E1
Рис.5 Тест Trixbox в режиме преобразователя SIP<->E1

На графике отчетливо видно периодическое увеличение количества SIP транзакций, и что наибольшее количество незначительных искажений приходится на участки (27..35) с интенсивным ростом количества звонков (5..15 cps), и load_avg растет именно в то время, когда рост количества звонков совпадает с "волнами" регистраций абонентов (на рис. 2 это видно не так хорошо). Не смотря на большую, по сравнению с тестом в режиме Trixbox, величину load_avg, искажения голоса минимальны. Вероятно, это обусловлено тем, что кроме самого VoIP сервера Asterisk никакое другое приложение не тратит ресурсы процессора, а Аsterisk отдает приоритет первоочередному обслуживанию RTP трафика, остальные, некритичные задачи ставятся в очередь. А так к величина load_avg отражает количество ожидающих обработки процессов, то можно сделать вывод, что обработка SIP сообщений откладывается, из-за чего load_avg растет синхронно с "волнами" перерегистрации. Начиная с 73-го отсчета, количество звонков практически не меняется, и искажения голоса отсутствуют.

Загрузка сервера Trixbox с отключеной функцией qualify и временем регистрации 1 час

Рис. 6 Загрузка сервера Trixbox с отключенной функцией qualify и временем регистрации 1 чаc

На рис. 6 приведен график параметров системы с отключенной функцией qualify и временем перерегистрации 3600 секунд. Значения  sip_calls на участках 9..25 и 33..45  сильно возрастают. это следствие процедур регистрации сначала одного, затем другого серверов, имитирующих абонентов. Так же как и в случае с режимом Trixbox, пропадания пакетов встречаются в периоды большого прироста новых звонков. Средняя загрузка процессора (load average, длинна очереди) значительно меньше - около 6,5 вместо 25, а количество одновременных sip транзакций (sip_calls) около 100, вместо 1000. Отмеченные потери пакетов носили единичный характер (прослушивание велось с помощью chanspy), а когда прослушивали непосредственно вызов (звонок с софтфона на софтфон), то никаких искажений или пропаданий пакетов не было и в помине.

В таком режиме и при полной загрузке всех 120 таймслотов четырех потоков E1 прослушивание велось в течении 40 минут. Несколько раз замечалось пропадание пакетов, но в целом качество голоса отличное, сервер Trixbox 300 способен обеспечить связью 1000 абонентов даже при максимальных и продолжительных нагрузках.

Тестирование в режиме SIP<=>SIP с простым диалпланом

После проведения основных тестов решено было попробовать исключить TDM звено из цепи обработки вызова, терминировать звонок непосредственно на SIP абонента. Для этого был незначительно изменен диалплан (команду набора Dial(ZAP/g1/${EXTEN}) заменили на команду вроде  Dial(SIP/${EXTEN})), никаких обработок звонка в AGI нет.

Загрузка Trixbox на более чем 200 одновременных звонков
Рис. 7 Загрузка Trixbox на более чем 200 одновременных звонков (у call_diff коэфф. 1)

С нагрузкой в 100 одновременных звонков Asterisk справился играючи, без намека на искажения или потери пакетов. Даже после увеличения количества вызовов до 150...180, load_avg в среднем не превышала 2. Немного повысить среднюю загрузку удалось интенсивно создавая/завершая множество звонков (участок 85..121). При этом зарегистрировано несколько случаев потери пакетов. В дальнейшем стало понятно, что качество голоса хорошее и не зависит от нагрузки (в измеряемых пределах). Была осуществлена попытка увеличить нагрузку до максимально возможной:

Попытка нагрузить Trixbox 300 максимально возможным количеством звонков
Рис. 8 Попытка нагрузить Trixbox 300 максимально возможным количеством звонков (у call_diff коэфф. 1)

К сожалению из-за особенностей скрипта, генерирующего вызовы, не удалось создать большую и равномерную нагрузку, но данные новых замеров (рис. 8) хорошо коррелируют с остальными: рост загрузки load_avg наблюдается в моменты максимальной скорости роста звонков. Но даже при трех сотнях одновременных вызовов пропадание пакетов - большая редкость, качество голоса достаточное для эксплуатации. 300 одновременных вызовов теоретически достаточно для телефонизации двух-трех тысяч абонентов, однако с увеличением количества услуг будет расти нагрузка при прежнем количестве абонентов.

Тест на надежность

Тестирование на надежность заключалось в продолжительном испытании Trixbox 300 под максимальной нагрузкой. Первоначально нагрузка была слишком большой, а так как всего было доступно 120 каналов, сервер не мог обработать все вызовы, часть звонков просто обивало по сигналу "занято" (рис. 9). Затем нагрузку уменьшили (рис. 10) и в течении первой недели сервер работал в режиме шлюза и успел обработать 750 тысяч вызовов (alaw; qualify=on; registertimeout=600). Основное тестирование на надежность длилось 6 недель. В режиме Trixbox на сервер была создана нормальная нагрузка в 50..60 вызовов, было обработано еще более 500 тысяч звонков. За все время тестирования (около двух месяцев) тестируемый сервер не перезагружали, не зарегистрировано ни одного сбоя, остановки или перезагрузки сервиса Asterisk. Температура помещения, в котором производился тест равнялась 27°С.

 
Рис. 9 Нагрузка более 120 каналов на Trixbox
(в течении первой недели теста)
Рис. 10 Нагрузка 120 каналов в режиме шлюза  Рис. 11 Нагрузка в 50 каналов в режиме Trixbox
(в течении четырех недель)
   
Рис. 11 Переход с режима шлюза в режим Trixbox Рис. 12 Загрузка в течении дня в режиме Trixbox

 

Использованные скрипты

Скрипт, формирующий call файлы: call-gen.php 
Скрипт, формирующий таблицу: asteriskcdrdb.stats.sql 
Скрипт для записи параметров системы: syswatch.php

 

  • 24/05/09
  • 1
  • Оценка: 2.26/5, голосов: 410

Комментарии

Тестирование Тrixbox 300 - Производительность Asterisk 2009-06-12 17:00 / #

Well done!

Оставить комментарий

Статьи

Корзина (0)

Корзина

Корзина пуста

Последние новости

X

Мы перезвоним Вам
за 60 секунд

Бесплатный звонок