1. Лабораторный стэнд
2. Тестирование утилитой sipp и Астериск 1.8

Лабораторный стэнд

---

Два сервера DELL T110:

• процессор Xeon E3-1220
• память 2Gb DDR3 RAM
• 500 HDD SATA 7200
• сеть 1Гбит/с

ОС и дополнительный софт:

• Centos 5.8 2.6.18-308.4.1.el5 x86_64
• FreePBX 2.10
• Asterisk 1.8.14.0
• sipp генерация нагрузки SIP
• мониторинг htop, atop

Тестирование утилитой sipp и Астериск 1.8

---

sipp 192.168.192.128 -s 100 -i 192.168.192.125 -d 100s -l 5000 -aa -mi 192.168.192.125 -rtp_echo -nd -r 10

192.168.192.128 — IP адрес SIP сервера, куда будут генерироваться вызовы

-s 100 — Указывает номер который будет вызван на SIP сервере

-i 192.168.192.125 — Локальный IP адрес. Этот адрес будет использован в SIP сообщениях в качестве адреса источника сообщений. По умолчанию используется адрес 127.0.0.1.

-d 100s — Устанавливает длительность звонков. Сейчас установлен в режим 100 секунд. Длительность по умолчанию — 1 секунда.

-l 5000 — Ограничивает максимальное количество одновременных звонков.

-aa — Включает автоматические ответы 200 OK на сообщения INFO, UPDATE и NOTIFY.

-mi 192.168.192.125 — Устанавливает локальный IP для RTP.

-rtp_echo — Включает режим RTP эха. Все RTP пакеты полученные от удалённой стороны — отправляются обратно.

-nd — Отключает стандартную обработку неожиданных ситуаций — sipp будет прерывать звонки в случае получения неправильных SIP сообщений.

-r 10 — Устанавливает максимальную «скорость звонков» (CPS) в данном случае — не более 10 звонков в секунду. По ходу работы утилиты sipp можно этот параметр регулировать клавиши +/- на Numpad

На сервере Астериск создаем SIP транк, например:

[sipp]
type=peer
context=in
defaultuser=sipp
host=192.168.192.125
dtmfmode=rfc2833
disallow=all
allow=ulaw
qualify=yes

2.1 Терминация на Playback

---

Простой диалплан:

[in]
exten ≥ 100,1,Answer ()
exten ≥ 100,n,Playback (/var/lib/asterisk/moh/02_MACROFORM_CANASTER)

htop — красиво показывает нагрузку на CPU

atop — показывает CPU, Network, загрузку файловой системы DSK

В данном случае 1 SIP канал = 1 Вызову call. Субъективный контроль на слух онлайн использовался chanspy. Музыку слышно с небольшим эхом, как и положено. Работает опция rtp_echo, которая возвращает RTP поток Астериска.

Визуальный контроль

2 экран sipp. Суммарная статистика за период

3 экран sipp. Скорость ответа Астериск в ms на запрос вызовы.

Краткое резюме на данном этапе тестирования:

Астериск успешно держит 2000 вызовов, загрузка ЦПУ около 60%, сеть 170Мбит/с

Увеличиваем до 2500 звонков. Эхо слышно сильнее, т.е. время на обработку медиа трафика увеличивается. Иногда слышны небольшие дефекты в звуке. Астериск держится, но уже появился WARNING.

Предельное количество вызовов при которых Астериск начинает некорректно обрабатывать звонки.

Критические ошибки посыпались после >2600 звонков

2.2 Терминация на MusicOnHold

---

Иногда спорят, что MusicOnHold сильного грузит CPU. Давайте посмотрим.

Диалплан:

[in]
exten ≥ 101,1,MusicOnHold ()

Дествительно, при 2000 вызовах уже наступил предел. На >1200 примерно начались искажение музыки в канале. На ранних версиях Астериск показатели могут быть и хуже. Поэтому тестирование на MusicOnHold неверное.

2.3 Проксирование: sipp — тестовый Астериск — терминация Астериск (Playback)

---

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

Настраиваем SIP транк аналогичный для второго сервера.

Диалплан на тестируемов (прокси):

[in]
exten ≥ 102,1,Dial (SIP/sipp/100)

Диалплан на втором сервере sipp (оригинация), Астериск (терминация):

[in]
exten ≥ 100,1,Answer ()
exten ≥ 100,n,Playback (/var/lib/asterisk/moh/02_MACROFORM_CANASTER)

Теперь 1 SIP вызов = 2 SIP канала.

1000 звонков, 2000 SIP каналов

1500 звонков, 3000 SIP каналов

1800 звонков, 3600 SIP каналов

Астериск держит каналы и обрабатывает звонки. Но в каналах иногда слышны небольшие потрескивания. Видим, что трафик уже 300 Мбит.

Пределом оказалось 1900+ звонков

2.4 Проксирование + Запись: sipp — тестовый Астериск — терминация Астериск (Playback)

---

Ну и конечно интересно, сколько же сможет писать таких звонков астериск на обычном SATA HDD 7,200, на встроенном контроллере. Тут atop и покажет узкое место в виде файловой системы.

Скорость диска на чтение:

[root@localhost asterisk]# hdparm -tT /dev/sda

/dev/sda:

Timing cached reads:  37120 MB in 1.99 seconds = 18608.60 MB/sec

Timing buffered disk reads: 388 MB in 3.00 seconds = 129.32 MB/sec

Диалплан тестирования:

[in]
exten ≥ 103,1,MixMonitor (/tmp/${UNIQUEID}.wav)
exten ≥ 103,n,Dial (SIP/sipp/100)

Хотя на слух все хорошо, но видно, что на большое количество одновременных записей скорости не хватает и возрастает latency на I/O. Опытным путем выяснилось, что планка в 400 звонков оказалась максимальной. При таком количестве звонков DSK sda/busy 100% то есть, то нет.

При 200 звонках busy прыгает до 60%

Резюме:

Хотя тест довольно «синтетический» не учитывает сложных логик диалплана, AGI, параллельной работы с АТС и т.п., но он показывает возможности версии Астериск 1.8.14 на конкретной железке Dell T110. Также нужно понимать, что если требуется запись большого объема одновременных звонков >100 на обычных SATA дисках, то без аппартного RAID контроллера не обойтись.