масштабируемость, отказоустойчивость

Подскажите, какое преимущество использования xml-curl перед использованием генерации диалплана локальным lua-скриптом. Кто что скажет?

вы его скриптом сейчас генерите или просто интересно?

у нас раньше было решение что xml генерили скриптом, а потом дёргали reloadxml.

Подскажите, какое преимущество использования xml-curl перед использованием генерации диалплана локальным lua-скриптом. Кто что скажет?

локальным это типа "положили на диск и сказали reloadxml"?

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

Подскажите, какое преимущество использования xml-curl перед использованием генерации диалплана локальным lua-скриптом. Кто что скажет?

все ограничения самого lua, если вам хватает возможностей lua тогда нет особых преимуществ

а еще есть формирование дп из модуля, типа managed или erlang (привет kazoo)

Сейчас на текущем фс скриптом lua. Но нужно поднять платформу для больших нагрузок, и хочу понять что использовать. Reloadxml не использую для применения настроек. Через mod_lua с использованием odbc диалплана динамический.

большие это сколько?

озаботились производительностью, когда в проде на 1 ноду был 1к каналов и до 250 cps

и питон вполне реально начал вставать раком

250цпс на 1к каналов? коллекторы чтоль?

я думаю вам надо смотреть в сторону xml_curl, отдавать с нгинкса, возможно через балансер

250цпс на 1к каналов? коллекторы чтоль?

просто облачная атс + несколько таксистов с сотней добавочных

когда в питере метро закрыли..

мда, у нас тоже бомбануло в такси, 1000+ человек на линии только в одной бизнес единице. 170 cps 3500 calls на узле

этот ад до глубокого вечера длился

В перспективе 3k одновременных. По cps не подскажу. Но хочу использовать несколько нод ФС закрытыми опенсипсом. По сути интересует производительность через mod_lua c odbc. Потянет ли хотябы тысячу одновременных одна нода ФС через луа

потестите sipp

lua тянет

выявите предел, потом решите, экспериментировать еще или распараллелить

с ним проблем вообще мало было

python java даже perl у нас был)))) lua сила

Тесты прогоняли, но это все же синтетика))

перл так-то норм

у нас тёк при нагрузке, сам mod_perl

но у всех языков свои тараканы

у нас тоже перл течёт

у нас тёк при нагрузке, сам mod_perl

кроме луа к фс ничего норм так и не прикрутили

lua интегрирована в freeswitch, будет полюбому быстрей всех внешних модулей

эт ясен пень

тут хрень в том, что кроме него все течет, ломается и кладет фс

если бы не быстрее луа, но норм работало было бы норм

ну как я вижу не ясен ?

?

еще прям на старой вики было написано, !!! луа самый быстрый, хотите юзать скрипты пишите их на луа !!!

"По сути интересует производительность через mod_lua"

lua интегрирована в freeswitch, будет полюбому быстрей всех внешних модулей

питон тоже интегрирован.. но там похоже gil дурит под нагрузкой

еще прям на старой вики было написано, !!! луа самый быстрый, хотите юзать скрипты пишите их на луа !!!

https://wiki.freeswitch.org/wiki/Which_scripting_language_should_I_use%3F пруфчик

ну и потечёт и какой-нибудь очень важный модуль к lua, в которой ничего нет и поэтому он такая быстрая ;)

https://wiki.freeswitch.org/wiki/Which_scripting_language_should_I_use%3F пруфчик

да да да

https://wiki.freeswitch.org/wiki/Mod_lua#Highly_Embeddable ещё

БД кстати кто какие юзает?

pg

couchbase, но решение так себе

couchbase, но решение так себе

поподробнее можно?

тоже интересно

nosql, под 5к гетов в секунду выжимал даже в тесте, но раму и проц жрёт не в себя

плюс есть баги типа "мемкэш клинит и он ест 100% ядра"

кластеризоваться не вышло, нельзя задать что читать всегда с себя, так что каждая нода это сингл-нодед кластер + xdcr (репликация такая)

С глюками связки mod_lua+odbc+mysql никто не сталкивался?

Хотелось бы использовать pgsql, но по условиям только мускул

pgsql

С глюками связки mod_lua+odbc+mysql никто не сталкивался?

а именно?

Хотелось бы использовать pgsql, но по условиям только мускул

драконовские условия)

вобщем если подытожить все юзают пг

кто как скармливает диалплан в фс? Соберу решения, потом в доку оформлю

Денис а где дока будет кстати?

Да в принципе, были ли какие-нибудь проблемы?

Коль никто не пишет, видимо не было)))

Да в принципе, были ли какие-нибудь проблемы?

не особо долго просидели на этом, писали вставки в ДП, была один раз хрень с тормозами именно mysql, параметры крутили и всё решалось, благо свалили и с одного и другого

имею ввиду и c lua и с mysql

Денис а где дока будет кстати?

могу в свой блог закинуть.. или в telegra.ph

мускуль под мелкие атс норм

под норм нагрузки - это фейл

да вот когда оно подрастать начало, крепко задумались о смене

геморроя было ппц

ERROR: S client not available

как минимум нужно тогда обвязать всякими redis

в итоге вообще отказались от скриптовых вставок в дп

у нас есть, но да, очень чревато

угу

поэтому всё вычисляется на стадии формирования дп

Добрые советы, всем благодарствую, учтем при реализации)))

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

вот мне очень нравится схема 2600hz в этом плане

вживую так и не потыкал ее

кстати rtmp еще кто нибудь юзает?)

видимо совсем нет)

Всем добрый вечер

прошу помощи с fs...

под норм нагрузки - это фейл

Мвтс категорически несогласны

имею допустим 2 fs на одном номера 1001...1009, на другом 7014101...7014111, обы через гетвеи подключены и звонки ходят в в оба конца

внутри каждого тоже все ходит и переключается

ситуация, абонент А с первого FS позвонил абоненту Б с первого FS, они пообщались и в результате разговора абонента А надо переключить на абонента Г на втором FS.

сделал <action application="bind_meta_app" data="6 ab s execute_extension::att_xfer_fil XML features" /> и добавил сам xfer <extension name="att_xfer_fil"> <condition field="destination_number" expression="^att_xfer_fil$"> <action application="read" data="3 7 'tone_stream://%(10000,0,350,440)' digits 30000 #"/> <action application="set" data="origination_cancel_key=#"/> <action application="att_xfer" data="${digits} XML default"/> </condition> </extension> в итоге в консоль падает [ERR] switch_core_session.c:510 Could not locate channel type 7014101 XML default тогда попробовал поменять <action application="att_xfer" data="${digits} XML default"/> на <action application="att_xfer" data="loopback/${digits}"/> в этом случае почему-то поиск совпадения по плану происходит только в контексте features и соответственно звонок не идет

посоветуйте где и что поправить

loopback/${digits} XML gw?

можно попробовать просто ${digits} XML external

только настроить этот контекст..

но мне надо чтобы проходил через контекс default

а с loopback/${digits} XML default что?

почему-то все равно ищется только в контексте features

ну сделай в features трансфер в default если так надо..

ну дак в итоге-то будет не att_xfer, а просто transfer?

att

или вопрос про статистику?

или я не так вас понял.. можно пример?

вот что при loopback Processing 1002 <1002>->7014101 XML default in context features loopback/7014101 XML default-b has executed the last dialplan instruction, hanging up.

значит нет диалплана на выполнение