Всем привет!

На неделе занимался оптимизацией алгоритмов исходящего обзвона в нашем продукте. Результаты показались убедительными - 10 000 звонов в час :)




Хочу поделиться, как этого добиться на сравнительно простом железе.

Конфигурация стенда:
- CPU Intel(R) Xeon(R) 2 ядра по 3GHz
- RAM 2 GB
- CentOS x86_64
- * 1.6.0.28
- PHP + MySQL
- Это виртуальный сервер под VMWare, который мы арендуем

Рекомендации:

* Отказаться от AGI в пользу FastAGI.

Даже на малых объемах - несколько звонков в секунду, AGI механизм ведет себя не совсем предсказуемо. Это проявляется, например, в виде лагов при исполнении PHP скриптов. Если при dial мы вызываем скрипт с insert в MySQL CDR, то при answer нет уверенности, что он уже выполнился и можно сделать update. Есть масса возмножных причин возникновения проблем, но в итоге я убедился, что они решаются переносом взаимодействия на уровень сокетов. Конфиги xinetd сами по себе достаточно гибко обеспечивают безопасность, дополнительно мы получаем возможность полностью вынести бизнес-логику с сервера телефонии.

* Не надеяться на соединение с AMI

AMI очень капризный. Первое - пришлось отказаться от поддержки постоянного соединения из скрипта прозвонки. AMI сессия открывается только чтобы выдать очередной пул originate, после этого закрывается до следующей итерации. (call файлы тоже наверное хорошо, но мы не используем)

* Не надеяться на запросы к AMI

В предыдущей версии мы вычисляли кол-во занятых каналов устанавливая каунтеры групп в dial-плане. Далее спрашивали AMI 'group show channels' и парсили. Иногда AMI не отвечал, и это ломало весь алгоритм прозвонки. В итоге перенесли всю real-time статистику в MySQL. (встроенный berkleydb тоже вариант, но руки не дошли)

* Не использовать скрипты из FreePBX

Это коррелирует с вопросом AGI/FastAGI... Не смотрел почему, но например 10-20 одновременных dialparties.agi просто забираю 99% CPU. (мы пока используем FreePBX как веб-интерфейс, но везде где можено переписываем dial-план)

p.s. с удовольствием пригласим поработать вместе людей, которым есть что добавить :)

Вадим Марков / Линия 24

1) Какбы это известно. Но я не сталкивался с таким вопиющим безобразием под аналогичными загрузками.
2) 100% согласен. Call файлы лучше не использовать, в некоторых версиях астера есть баги, которые не исправлены и приводят к непонятному одновременному (!) исполнению всех приоритетов диалплана или типа того.
3) такого эффекта не встречал даже под нагрузками. скорее всего проявлялся у вас при наличии п.1.
4) Да это бич, серьезно ограничивающий производительность системы. для чего их там столько - не понятно, можно прекрасно и без них обходиться. Но опять же, при намного менее мощной системе (Р4 2.4), 80 одновременных звонков при 20 dialparties.agi дает LA 2.0. Загрузка CPU в линухе - плохой показатель.

>* Отказаться от AGI в пользу FastAGI.
я бы рекомендовал вообще от скриптов отказаться;) понятно, запуск 5 тяжелых скриптов пхп не очень нравиться серверу, НО я имею опыт настройки a2billing, который использует как раз АГИ скрипты, и нагрузка в 5 звонков в сек для него багов не вызывает. может что-то не так с вашими сриптами? )
>* Не надеяться на запросы к AMI
а что мешало генерить евенты и тестить количество звонков диалпланом? не замечал никаких пробелм с генерацией евентов, если АМИ только в режиме прослушки багов не наблюдаеться(все выловлены разработчиками FOP)


а можно поподробнее про баги в файлах?
у меня все мои диалеры используют чистый диалплан без скриптов, оригинация через call-files и ни загрузки ни багов не замечено пока.

баги были замечены на trixbox 2.3, на 2.6 тоже вроде было, но точно не могу сказать.
Проявлялось не всегда, да и не сразу заметишь, ибо с виду все нормально. Идея была в том, чтобы воспроизводить фразу о подъехавшем такси. Call файл соединял два контекста: в одном голосовое меню, в другом - исходящая маршрутизация.
так вот исходящая маршрутизация и мудила: отрабатывали сразу все приоритеты экстеншена. Это приводило к тому, что звонки через гсм шлюз шли через все каналы одновременно, не смотря на то, что DIAL прописаны последовательно

Касаемо AGI vs FastAGI. Скрипты все таки разные бывают, если нужно сделать, что то простое и быстрое то да - FastAGI, если скрипты делают, что то более сложное то проще запустить один AGI скрипт и пусть он болтается, память щас дешевая... Совсем без скриптов, как предложил meral, это IMHO от лукавого, ибо это либо совсем простой диал план, либо внутри куча system, что один фиг порождает форки...

На домашней, тестовой, машинке Intel(R) Core(TM)2 Duo CPU E6850@3.00GHz - 15 звонков в секунду вполне себе ничего отрабатывается, правда perl а не php.

Я вообще не использую AGI. Сделал выбор в сторону ODBC+Postgres. Количество текущих занятых каналов сохраняется в БД, сам автообзвонщик работает на perl+AMI.

ни знаю,не встречал почемуто таких багов.

Совсем без скриптов, как предложил meral, это IMHO от лукавого, ибо это либо совсем простой диал план, либо внутри куча system, что один фиг порождает форки...
.

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

необходимость вызова system в серйозном проекте с астериском говорит о том, что вы недостаточно представляете возможности диалплана самого астериска. если так - то да, вам проще фастАГИ мучать. я тоже использую его если есть необходимость сложного расчетов или взаимодействия с базой либо кеширования результатов. но для диалера и информатора это явно избыточно. диалер работает просто: есть куча номеров, надо максимально полно задействовать каналы и по всем позвонить. результаты звонков можно считать с сдр, и ниначто не повлияет если вы про неудачузвонка на некий номер узнает на 10 секунд позже. наибольшая проблема каунты каналов - реализуеться в диалплане через Set(GROUP()=) и соответсвенно через проверки, что еше не максимум. если максимум, то просто поставить в сдр значок "перезвонить, количество попыток не увеличивать ибо было неверное планирование".
далплан с этим ПРЕКРАСНО справляеться. все же люди пишут похожие задачи и добавляют необходимые команды в диалплан.

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

to meral: я не про диалер конкретно, а про отказ от (Fast)AGI впринципе...

да в любом случае если вы используете system, то что то у вас не так.развешо использоваться будет с минимальной нагрузкой или редко.
я использую fastAGI через perl-POE, ибо он пулы мускл нормально отрабатывает. если система не требует кучи запросов к БД на звонок, то лучше использывать чистый диалплан.

system, мне почему то кажется еще большим злом нежеле простоAGI.

по поводу хождения в базу из диалплана - поддерживать потом ЭТУ смесь из экранированных сиквельных запросов и собственно самого диалплана. ну уж нет. спасибо. А от кучи запросов в БД очень помогают всякие memcached'ы, опять таки которые просто так из диалплана не прикрутишь.

В общем то, что я хотел сказать - использовать ли AGI/FastAGI/или_просто_AEL сильно зависит от ситуациии, не факт, что 3 экрана ael скрипта ходящего в БД и потом чего то считающего, будет быстрее вызова FastAGI который мгновенно отдаст значение из кеша, так же как и не факт того, что дергать 50 раз, через строчку диалплана, FastAGI скрипт будет быстрее чем запустить один раз AGI и выполнить нужные действия с теми же 50-ю командами диалплана.