Не очень понял, если честно. Вы к тому что на каждый звонок дергается этот скрипт?
Пример
local log, err = io.open("/tmp/pbx_lua.log","a")
if log then
log:setvbuf("no")
log:write('--- iteration ---\n')
log:close()
end
extensions = {
lua = {
["000"] = function(context, extension)
app.Verbose("---------------- Test LUA Call -------------------------")
end
}
}
Один звонок и смотрим в /tmp/pbx_lua.log, удивляемся…
Лучше новый tcp коннект, чем такое.
Но и тут можно найти решение. Например у меня на нагруженных системах у каждого астериска есть своя реплика postgresql с которой он читает + коннект через сокет файл.)
Тоже решение так себе если честно. Нагруженный сервер(asterisk), база(postgre), что то еще и все на одной "бочке", я бы разнес. Прелесть lunaparka'а в асинхронности — это как nodejs и nginx(nginx скорее event driven, но не суть) с одной стороны и apach prefork с другой.
По поводу realtime'а — возможно вы правы, но мне на транзите его хватает с лихвой.
Цепляете ли к одному сервису больше 1 астериска? Или 1 lunapark = 1 астериск?
Тут как бы из архитектуры все ясно. FastAGI — цепляем кучу *, а вот с AMI — один слушатель/клиент, один астер.
Хочется знать сколько звонков и какой cps вытянет lunapark
Выше писал про тесты, на "боевых" трафик размеренный, больше 64 в cps я и не видел. Из того, что имею для тестов это учетки мультифон-бизнес, с учетом многоканала(300 каналов) отрабатывают все. И это не какой то sipp тест, а с полноценным звонком на 0500 и записью.
Интересный проект конечно, но чисто из академического интереса. pbx_lua вполне себе.
Так вот именно, что НЕ вполне. Сделайте тестовое логирование в extensions.lua, в самом начале перед формированием таблицы extensions. Сильно удивитесь при звонке.
А интерес то может быть и академический, только вот на основе такого проекта вполне себе успешно перемалывается куча voip трафика с lcr, fas detection и цепочек маршрутов.
Проблемы с пользователями, очередями и в целом с механизном realtime.
А что с realtime в астериске не так, как раз там то все вполне себе. А очереди, лично я, реализовал на основе lunaparka как voip-приложение.
Бытует мнение что при увеличение нагрузки и усложнении логики вы можете упереться в ресурс одного ядра и как следствие замедление работы asterisk.
Бытует мнение, что настаящая многозадачность возможна только на многопроцессорных системах. Все остальное это псевдо-многозадачность, в которой накладные расходы по переключению задач куда значительней чем на переключение контекстов в сопраграммах.
Те же очереди заставили нас призадуматься, lua и asterisk не лучший выбор
Если вы под lua имеете в виду pbx_lua, то это не то, в посте/статье описывается совсем другой подход, в посте не используется астерисковский pbx_lua. А по поводу последнего я высказался в самом посте.
Так же хочу отметить что asterisk, к сожалению, не про скорость, как мне кажется. Это скорее не болид, а комбайн с пекарней и магазином на борту, дает много функционала, но жертвует «скоростью».
Вы сейчас перефразировали посыл поста. Я про то же, ни что не мешает выкинуть пекарню, магазин и прочее с борта, есть вероятность что получите скорость.
Про chan_sip — что есть то есть, тут уж ни чего не поделаешь, а вот pjsip — это вы зря.
например lua.mysql(dba конечно спасибо не скажут).
Сейчас точно уверен, что вы о pbx_lua — еще раз акцентирую внимание на том что в посте совсем другой подход. Асинхронность требует определенного подхода, вы не можете внутри асинхронного кода просто вызвать конект к базе и выполнить запрос. Точнее можете, ни кто вам не помешает, но если запрос подвиснет, то подвиснет вашь поток.
Так ARI то тоже парсится постоянно, ну, разве что в JSON и только подписанные события. А если вам нужны ВСЕ события, кроме скажем десятка из тысячи, вы оформляете подписку на нужные. Тоже прекрасно реализовывается через eventfilter.
Хочу акцентировать внимание на том, что я не против ARI, я лишь топлю за то, что потенциал AGI/AMI не используется даже на 50% своих возможностей.
В AMI то же. Только делается это не очевидными способами. Да и eventfilter еще ни кто не отменял.
и вообще ее не измеряете, как и нагрузку.
Измеряю, но не публикую, ибо смысл вне сравнения. Я могу написать, что аналогичные подходы упираются в пропускную способность сети, а никак не в производительность сервера. Но это все вода без противоположенных результатов тестов.
Основной посыл поста — это не тесты производительности в сравнении, а то, что его (asterisk) не умеют "готовить".
что диалплан, что lua где-то на одном уровне как по понятности так и по выразительности.
С чистым диалпланом не сравнивал, так как давно перешел на аналогичные системы управления.
Если тесты накидаете, могу заморочиться.
на первом месте диалплан+func_odbc+ cel
Вынужден не согласиться, CEL еще тот монстр.
Lua и AMI все же прилично грузят систему
Но не в этом случае. AMI из всех возможных подходов самый легковесный, а Lua, в данном случае, вообще вынесен из астериска во вне.
Опять-таки, luajit. Можно же lunapark через него запустить.
Хм, странно. Lua как раз и был выбран из-за его простоты и наглядности.
По поводу WebRTC — я придерживаюсь мнения, что Кесарю кесарево, а браузеру браузерово. Ну, то есть, web — это web, а voip — это voip и лучше их не смешивать.
Если же нужно web звонилку, то юзаю kamailio с rtpengine и в астериск приходит чистый VoIP. Лучше этого пока не нашел.
С PJSIP да, согласен — хотели как лучше, а получилось как всегда. Можно же было поменять движок, но оставить синтаксис тех же конфигов.
Привет землякам…
Почему не AsyncAGI? Хм, наверное, потому что это AGI контрролируемый через AMI, а это и так реализовано в lunopark'е.
Мы же можем накатать что-то типа:
ami.removeEvents('*')
ami.addEvent('AsyncAGI',function(e)
if e['SubEvent'] and e['SubEvent'] == 'Start' then
ami.Agi{channel = e['Channel'], command = 'VERBOSE "Processing inside AsyncAGI"'}
ami.Agi{channel = e['Channel'],command = 'ASYNCAGI BREAK'}
end
end)
Но это, ну так себе, не красиво. Да и согласитесь с FastAGI как-то по понятней получилось.
Пример
Один звонок и смотрим в /tmp/pbx_lua.log, удивляемся…
Лучше новый tcp коннект, чем такое.
Тоже решение так себе если честно. Нагруженный сервер(asterisk), база(postgre), что то еще и все на одной "бочке", я бы разнес. Прелесть lunaparka'а в асинхронности — это как nodejs и nginx(nginx скорее event driven, но не суть) с одной стороны и apach prefork с другой.
По поводу realtime'а — возможно вы правы, но мне на транзите его хватает с лихвой.
Тут как бы из архитектуры все ясно. FastAGI — цепляем кучу *, а вот с AMI — один слушатель/клиент, один астер.
Выше писал про тесты, на "боевых" трафик размеренный, больше 64 в cps я и не видел. Из того, что имею для тестов это учетки мультифон-бизнес, с учетом многоканала(300 каналов) отрабатывают все. И это не какой то sipp тест, а с полноценным звонком на 0500 и записью.
хм, тут больше от запросов в базу зависит, а не от lunapark'а
Так вот именно, что НЕ вполне. Сделайте тестовое логирование в extensions.lua, в самом начале перед формированием таблицы extensions. Сильно удивитесь при звонке.
А интерес то может быть и академический, только вот на основе такого проекта вполне себе успешно перемалывается куча voip трафика с lcr, fas detection и цепочек маршрутов.
А что с realtime в астериске не так, как раз там то все вполне себе. А очереди, лично я, реализовал на основе lunaparka как voip-приложение.
Ну как сказать. Гляньте в modules.conf, все ли там "несущие".
Встречный вопрос, какой cps для вас выше среднего?
Асинхронностью, не синхронные запросы к базе и т.д. и т.п.
Бытует мнение, что настаящая многозадачность возможна только на многопроцессорных системах. Все остальное это псевдо-многозадачность, в которой накладные расходы по переключению задач куда значительней чем на переключение контекстов в сопраграммах.
Если вы под lua имеете в виду pbx_lua, то это не то, в посте/статье описывается совсем другой подход, в посте не используется астерисковский pbx_lua. А по поводу последнего я высказался в самом посте.
Вы сейчас перефразировали посыл поста. Я про то же, ни что не мешает выкинуть пекарню, магазин и прочее с борта, есть вероятность что получите скорость.
Про chan_sip — что есть то есть, тут уж ни чего не поделаешь, а вот pjsip — это вы зря.
Сейчас точно уверен, что вы о pbx_lua — еще раз акцентирую внимание на том что в посте совсем другой подход. Асинхронность требует определенного подхода, вы не можете внутри асинхронного кода просто вызвать конект к базе и выполнить запрос. Точнее можете, ни кто вам не помешает, но если запрос подвиснет, то подвиснет вашь поток.
Если коротко, то в лог/stderr падает ошибка с причиной и т.д и т.п. и работа продолжается.
Измерений как таковых нет, задачи не стояло.
Да вы правильно поняли — однопоток, кооперативная многозадачность в чистом виде. То что касается масштабирования — по ка даже не задумывался.
Так ARI то тоже парсится постоянно, ну, разве что в JSON и только подписанные события. А если вам нужны ВСЕ события, кроме скажем десятка из тысячи, вы оформляете подписку на нужные. Тоже прекрасно реализовывается через eventfilter.
Хочу акцентировать внимание на том, что я не против ARI, я лишь топлю за то, что потенциал AGI/AMI не используется даже на 50% своих возможностей.
В AMI то же. Только делается это не очевидными способами. Да и eventfilter еще ни кто не отменял.
Измеряю, но не публикую, ибо смысл вне сравнения. Я могу написать, что аналогичные подходы упираются в пропускную способность сети, а никак не в производительность сервера. Но это все вода без противоположенных результатов тестов.
Основной посыл поста — это не тесты производительности в сравнении, а то, что его (asterisk) не умеют "готовить".
Хм, громкое заявление. Впрочем, тут уж кому как.
С чистым диалпланом не сравнивал, так как давно перешел на аналогичные системы управления.
Если тесты накидаете, могу заморочиться.
Вынужден не согласиться, CEL еще тот монстр.
Но не в этом случае. AMI из всех возможных подходов самый легковесный, а Lua, в данном случае, вообще вынесен из астериска во вне.
Опять-таки, luajit. Можно же lunapark через него запустить.
Хм, странно. Lua как раз и был выбран из-за его простоты и наглядности.
По поводу WebRTC — я придерживаюсь мнения, что Кесарю кесарево, а браузеру браузерово. Ну, то есть, web — это web, а voip — это voip и лучше их не смешивать.
Если же нужно web звонилку, то юзаю kamailio с rtpengine и в астериск приходит чистый VoIP. Лучше этого пока не нашел.
С PJSIP да, согласен — хотели как лучше, а получилось как всегда. Можно же было поменять движок, но оставить синтаксис тех же конфигов.
Привет землякам…
Почему не AsyncAGI? Хм, наверное, потому что это AGI контрролируемый через AMI, а это и так реализовано в lunopark'е.
Мы же можем накатать что-то типа:
Но это, ну так себе, не красиво. Да и согласитесь с FastAGI как-то по понятней получилось.