Ни кто не утверждал что он причем. Странная СУБД Oracle - это да, но не ....
Дело либо в драйвере к нему, либо в клиентском коде.
Ну да, ну да. libclntsh.so во всех случаях одна и та же. Код проще некуда: connect/preparee/execute и последующий json. Но виноват кто угодно только не язык реализации коннектора.
Из тех кто завелись с первого раза и без каких либо вопросов/твиков - это DBI-Perl и JDBC. Возиться и подкручивать что то в драйвере языка-реализации(кроме lua, с ним повозился) не было ни желания ни времени, а с java'ой я не очень дружу. Да и DBI-Oracle просто работает.
P.S.
Сильно разочаровал lua, так как окружение openresty, то хотелось обойтись штатными средствами, но видать не судьба.
Я не буду спорить в части специфики языков и тюнинга, возможно все так как Вы пишите. DBI-Oracle то же куча крутилок о назначении которых я ни чего не знаю, но он просто работает в дефолтном виде.
Тем не менее это факт, можете сами проверить. Да и не забывайте, что Oracle сама по себе оооочень странная BD. Так что, рановато ещё perl хоронить — откапывайте.
Делал как-то sql-over-http для Oracle базы, так ни один из языков прослойки (python/php/lua) не смог отдать полностью бооольшой выхлоп от базы. Только DBI-Oracle смог справиться с этой задачей как и N-цать лет назад..
Это не отменяет того факта, что однажды chan_sip перейдет в состояние поддержки dropped
Как и факт того, что PJSIP не решает проблемы массового Realtime. Переводить окружение из примера в статье на pjsip, что бы поиметь все те же проблемы, ну такое себе занятие.
Вы же понимаете, что были, есть и будут legacy-площадки где pjsip не то что-бы не нужен, он там просто не дает ни какого профита, как минимум.
В том смысле, что если утечки есть (ошибки в коде), то они будут вне зависимости от количества пиров. Маловероятно, что бы race condition увеличивал объем утечки.
А вот не факт, помимо состояния гонки есть куча узких мест, тот же накопительный эффект по буферам.
воспринималась и реализовывалась как дополнение к решению на основе выноса регистраций на внешний сервер.
Это как раз и есть решение с registrar server и именно на kamailio. А решение с кэшем - это попытка понять, как победить realtime и много пиров без registrar server и возможно ли такое в принципе
Вот уж действительно. Наверное именно поэтому nginx ставят перед кластером nodejs
А когда это в нашей дискуссии передергивание стало заходит как аргументация? Че так можно было…
Я вам про теплое, Вы мне про мягкое. Не зачет.
Да и пусть не дают.<...>Да, стартует дольше и подключает либы каждый сам, да не шарит контекст, но все это решается или локализацией данных или прокидыванием через внешние источники типа shmem/redis/htable.
Я Вас правильно понимаю, что агитация(то что вас и подорвало изначально) за AMI/AGI/ARI сервисы в простых задачах это зло, а то же самое но в вашей интерпретации это уже добро. Чет тут кто то сам себе противоречит.
Статику вычитываем при изменениии кэшируем. Done. Более того, это ещё ещё читать потом проще, нежели искать — а что тут контекстное, а что не контекстное.
В моем предложении, вот всего этого просто не нужно, данные, состояние, оно вот оно, перед вами. Нет необходимости в shmem/redis/htable, а с tarantool'ом мы еще и базу/умный кэш имеем.
Ведь окажется что вы утыкаетесь в производительность однопоточного сервиса гораздо раньше чем хотели бы этого
Вы не можете аргументированно спорить на эту тему, так как не понимаете/не вникали в архитектуру, это спор ради спора.
Вы же в курсе(я надеюсь), что ваша многозадачность — это псевдо многозадачность. Реальный параллелизм вы получите на многопроцессорной системе и только на ней. В таком контексте Ваше замечание про 1 ядро становится мягко говоря не состоятельным.
Что вам мешает запустить энное количество экземпляров на каждом ядре вашего сервера, возбуждаясь каждый раз от осознания того что оно многозадачное.
А теперь вдруг переобулись в то, что это неэффективно оказывается, что это просто блажь с которой вообще непонятно зачем возились
Опять двадцать пять — это ваши домыслы не более, весь тред перед вами, ткните где я однозначно высказался про ненужность. Есть такое понятие — целесообразность, вами же к стати предложенное.
В общем — слова как лава горячи, но смысла мало в них, увы.
Давайте притворимся, что я с вами согласен и действительно закончим на этом и по PJSIP то же!
16-й, я вас умоляю, видимо ваш "большой прод" большой только по вашим меркам. Вы же за конкретику, давайте цифры. Объёмы, окружение, организация учеток, тип трафика, количество и т.д. и т.п.
Без таких данных, это все пустые слова, не более.
Отдельная функция PJSIP_DIAL_CONTACTS добавляет гибкости
Пришли к тому с чего начали. Нужна мне в очереди фича вызова всех зареганных из под учетки — костыляем контексты и локал. Это не субъективно, а объективно, херь какая то.
Это началось здесь и закончится должно тоже здесь. У Вас какая то каша, куча штампов и стереотипов. Но вы не переживайте я вам помогу разобраться.
Я понял так как написали
Чукча не читатель, чукча писатель…
Ещё раз, напишу по другому. Вы же должны понимать степень упрощения задачи. Возможно, где то и есть сервер, единственной задачей которого, является originate, без проверок и связей. Так вот, проецируйте мой пост для всех остальных случаев, там где есть хоть какой то бэкгроунд.
С потоками давно уже все проще чем вы представляете.
Да что Вы, правда. А ну ка, расскажите мне, как наши космические корабли бороздят просторы Вселенной… Что там существенно поменялось/упростилось. Если в вашем фрэймворке/либе(чё вы там используете) реализован слой абстракции, упрощающий написание мультипотокового приложения, то это мимо кассы. Под капотом то же IPC, блокировки и иже с ними.
Ещё раз — передача контекста выполнения в многопоточном приложении, в определенный момент, под нагрузкой, становится слишком дорогим и по*еру сколько у вас ядер.
брать его именно чистую имплементацию без обёртки в LVM менеджера — спорное решение хотя бы потому, что вы задействуете только 1 ядро вашего сервера. Такова изначальная природа Lua. Это встраиваемый язык.
Вы путаете причинно следственную связь. Lua и однопоток — это все следствие асинхронности она обязательное условие. Именно она дает значительный boost при работе с данными, общими. Openresty/Nginx, HAproxy да и Kamailio не дают сохранения состояния(разделение контекста/окружения между двумя параллельными вызовами) и общий доступ — это не то пальто. Юзать такие LVM, ради многопоточности, спорное решение.
При разработке ни одной ноги не пострадало, в продакшене это решение реализовано в окружении tarantool'а. А там(опять сюрприз) сервер приложений в одном потоке.
Нагрузка, на рабочих стендах не держит объемы, там где chan_sip отрабатывал.
Текёт, ой как текёт, там где chan_sip кряхтел но отрабатывал, pjsip отсылает к памяти.
Претензия же, по поводу не верного пути, больше относится к PJSIP_DIAL_CONTACTS. Почему не сделать Dial(PJSIP....) и сразу все звонят? Нет, я могу понять, что не всегда нужен вызов всех зарегистрированных под учеткой и кодовую базу приложения Dial не хочется менять, но тогда смысл во множественной регистрации, если обработку её выносим из канала. Как то не логично.
но я считаю, что проблемы нужно искать там, где они есть
Складывается такое впечатление, что где-то там в offline Вас насильно заставляют юзать интеграционные решения вместо теплого и уютного диалплана. А как же развитие?
сорян, как у вас написано-так и понял
Нет, вот именно, Вы поняли так как Вам хочется. Искусственно создали причину и пытаетесь в чем то меня переубедить. Вы думаете что я не понимаю целесообразность того или иного подхода? Ошибаетесь, именно потому, что предложил свои правки. Но, Вы как то узко зацепились за примитивную задачу и доказывает очевидное. Реальные системы не останавливаются на примитивах cid/cdr, есть связи с системами биллинга, статистики, мониторинга и т.д. и т.п. Сюрприз, сюрприз, иногда нужно межсистемные взоимодействия в обе стороны. В таких случаях продолжайте комуницировать как хотите, а я буду настаивать, что интеграция со сторонними сервисами(там где это уместно) пока наилучший вариант.
использовать однопоточный Lua как external сервис
Пока условный Вы будете возится с IPC, консистентностью и синхронизацией разделяемых данных в многопотоке, условный я будет просто обрабатывать звонки.
корутина блокирует выполнение других задач
Судя потому, что Вы это пишите, Вы не слишком понимаете в кооперации. Если это не так, то Вы должны были слышать о C10K и как проблема успешно решалась с использованием кооперативной многозадачности. Из примерно 10K условных соединений сдохнет скорее Астериск и pjsip в частности, а не external сервис на корутинах(при условии написания в кооперативном стиле).
Ваше принципиальное заблуждение — "корутина блокирует выполнение других задач", а смысл как раз противоположен. Корутина уступает контекст выполнения при простое/ожидании.
PreFork/etc в highload в 21-м году мало кто рассматривает, а вот асинхрон и событийный подход да, как Вы думаете почему?
Какие два цвета, о чем Вы...
Мне кажеться, что Вы путаете мягкое и теплое, в чем противоречия:
Осмысленный подход к проектированию
Интеграция уже имеющейся кодовой(диалплан/ami/agi) базы со сторонними сервисами
Четкое понимание того, что гадить в диалплан нужно осмысленно, с понимание того что в итоге получиться
Хоть какое то понимание о нагрузке/производительности в итоге
Вы считаете, что это НЕ нормально?
перепиливать все под чистую на ARI если этого не требует сервис
Такое впечатление, что Вы проецируете свои профессиональные комплексы прямо сюда. Ну не срастается у вас с ARI, так и черт с ним.
Прочитайте мой пост, я там более чем доходчиво высказал свое мнение про ARI и иже с ними.
А просто прийти и сказать со стороны у вас тут все неправильно
Откуда Вы вообще взяли все эти фантазии, где упоминалось об — "вам нужно все начать сначала и написать с нуля". И вообще, такое впечатление, что вы не слишком поняли то что я пытался донести своими коментариями.
А Вы видимо агетирует за стагнацию, как было написанов 2000-ых так и шпарим дальше.
Без развития любой проект обречен в лучшем случае на безвестность. А развитие, в свою очередь, предполагает некоторое проектирование, а не тяп ляп и в продакшен.
Но кто я такой чтобы говорить об этом.
Уже давно агитирую за упрощение процесса "пищеварения" для астера, астер уже не торт и с каждым новым релизом это проявляется все ярче и красочней.
Один из способов — это упростить астеру жизнь, сделать из него медиа-хаб, простые примитивы(answer/hangup/redirect/bridge/etc), а логику и телодвижения выносить на сторонние сервисы.
Астериск уже давно готов к интеграционным решениям, ARI/FastAGI/etc.
Такие вещи, как в посте, реализовываются при таком подходе вообще прозрачно и без каких нибудь умственных страданий.
Ни кто не утверждал что он причем. Странная СУБД Oracle - это да, но не ....
Ну да, ну да. libclntsh.so во всех случаях одна и та же. Код проще некуда: connect/preparee/execute и последующий json. Но виноват кто угодно только не язык реализации коннектора.
Из тех кто завелись с первого раза и без каких либо вопросов/твиков - это DBI-Perl и JDBC. Возиться и подкручивать что то в драйвере языка-реализации(кроме lua, с ним повозился) не было ни желания ни времени, а с java'ой я не очень дружу. Да и DBI-Oracle просто работает.
P.S.
Сильно разочаровал lua, так как окружение openresty, то хотелось обойтись штатными средствами, но видать не судьба.
Только буферизацию nginx'а.
Я не буду спорить в части специфики языков и тюнинга, возможно все так как Вы пишите. DBI-Oracle то же куча крутилок о назначении которых я ни чего не знаю, но он просто работает в дефолтном виде.
Тем не менее это факт, можете сами проверить. Да и не забывайте, что Oracle сама по себе оооочень странная BD. Так что, рановато ещё perl хоронить — откапывайте.
Делал как-то sql-over-http для Oracle базы, так ни один из языков прослойки (python/php/lua) не смог отдать полностью бооольшой выхлоп от базы. Только DBI-Oracle смог справиться с этой задачей как и N-цать лет назад..
Как и факт того, что PJSIP не решает проблемы массового Realtime. Переводить окружение из примера в статье на pjsip, что бы поиметь все те же проблемы, ну такое себе занятие.
Вы же понимаете, что были, есть и будут legacy-площадки где pjsip не то что-бы не нужен, он там просто не дает ни какого профита, как минимум.
А вот не факт, помимо состояния гонки есть куча узких мест, тот же накопительный эффект по буферам.
Вот в этом то и вся соль
Простите, на основании чего Вы пришли к такому выводу?
Почему за сутки? Месяц +/-. Световой день в посте в кавычках - аллегория.
попробуйте увеличит количество пиров до 5000 +/-, картина поменяется кардинально.
Это как раз и есть решение с registrar server и именно на kamailio. А решение с кэшем - это попытка понять, как победить realtime и много пиров без registrar server и возможно ли такое в принципе
сориентируйте по количеству пиров на единицу астериска
Несколько десятков машин, несколько миллионов в день…
Но это правда, мамой клянусь, есть такой сервис в природе.
А когда это в нашей дискуссии передергивание стало заходит как аргументация? Че так можно было…
Я вам про теплое, Вы мне про мягкое. Не зачет.
Я Вас правильно понимаю, что агитация(то что вас и подорвало изначально) за AMI/AGI/ARI сервисы в простых задачах это зло, а то же самое но в вашей интерпретации это уже добро. Чет тут кто то сам себе противоречит.
В моем предложении, вот всего этого просто не нужно, данные, состояние, оно вот оно, перед вами. Нет необходимости в shmem/redis/htable, а с tarantool'ом мы еще и базу/умный кэш имеем.
Вы не можете аргументированно спорить на эту тему, так как не понимаете/не вникали в архитектуру, это спор ради спора.
Вы же в курсе(я надеюсь), что ваша многозадачность — это псевдо многозадачность. Реальный параллелизм вы получите на многопроцессорной системе и только на ней. В таком контексте Ваше замечание про 1 ядро становится мягко говоря не состоятельным.
Что вам мешает запустить энное количество экземпляров на каждом ядре вашего сервера, возбуждаясь каждый раз от осознания того что оно многозадачное.
Опять двадцать пять — это ваши домыслы не более, весь тред перед вами, ткните где я однозначно высказался про ненужность. Есть такое понятие — целесообразность, вами же к стати предложенное.
В общем — слова как лава горячи, но смысла мало в них, увы.
Давайте притворимся, что я с вами согласен и действительно закончим на этом и по PJSIP то же!
16-й, я вас умоляю, видимо ваш "большой прод" большой только по вашим меркам. Вы же за конкретику, давайте цифры. Объёмы, окружение, организация учеток, тип трафика, количество и т.д. и т.п.
Без таких данных, это все пустые слова, не более.
Пришли к тому с чего начали. Нужна мне в очереди фича вызова всех зареганных из под учетки — костыляем контексты и локал. Это не субъективно, а объективно, херь какая то.
Это началось здесь и закончится должно тоже здесь. У Вас какая то каша, куча штампов и стереотипов. Но вы не переживайте я вам помогу разобраться.
Чукча не читатель, чукча писатель…
Ещё раз, напишу по другому. Вы же должны понимать степень упрощения задачи. Возможно, где то и есть сервер, единственной задачей которого, является originate, без проверок и связей. Так вот, проецируйте мой пост для всех остальных случаев, там где есть хоть какой то бэкгроунд.
Да что Вы, правда. А ну ка, расскажите мне, как наши космические корабли бороздят просторы Вселенной… Что там существенно поменялось/упростилось. Если в вашем фрэймворке/либе(чё вы там используете) реализован слой абстракции, упрощающий написание мультипотокового приложения, то это мимо кассы. Под капотом то же IPC, блокировки и иже с ними.
Ещё раз — передача контекста выполнения в многопоточном приложении, в определенный момент, под нагрузкой, становится слишком дорогим и по*еру сколько у вас ядер.
Вы путаете причинно следственную связь. Lua и однопоток — это все следствие асинхронности она обязательное условие. Именно она дает значительный boost при работе с данными, общими. Openresty/Nginx, HAproxy да и Kamailio не дают сохранения состояния(разделение контекста/окружения между двумя параллельными вызовами) и общий доступ — это не то пальто. Юзать такие LVM, ради многопоточности, спорное решение.
При разработке ни одной ноги не пострадало, в продакшене это решение реализовано в окружении tarantool'а. А там(опять сюрприз) сервер приложений в одном потоке.
Да как же так то...
Претензия же, по поводу не верного пути, больше относится к PJSIP_DIAL_CONTACTS. Почему не сделать Dial(PJSIP....) и сразу все звонят? Нет, я могу понять, что не всегда нужен вызов всех зарегистрированных под учеткой и кодовую базу приложения Dial не хочется менять, но тогда смысл во множественной регистрации, если обработку её выносим из канала. Как то не логично.
Складывается такое впечатление, что где-то там в offline Вас насильно заставляют юзать интеграционные решения вместо теплого и уютного диалплана. А как же развитие?
Нет, вот именно, Вы поняли так как Вам хочется. Искусственно создали причину и пытаетесь в чем то меня переубедить. Вы думаете что я не понимаю целесообразность того или иного подхода? Ошибаетесь, именно потому, что предложил свои правки. Но, Вы как то узко зацепились за примитивную задачу и доказывает очевидное. Реальные системы не останавливаются на примитивах cid/cdr, есть связи с системами биллинга, статистики, мониторинга и т.д. и т.п. Сюрприз, сюрприз, иногда нужно межсистемные взоимодействия в обе стороны. В таких случаях продолжайте комуницировать как хотите, а я буду настаивать, что интеграция со сторонними сервисами(там где это уместно) пока наилучший вариант.
Пока условный Вы будете возится с IPC, консистентностью и синхронизацией разделяемых данных в многопотоке, условный я будет просто обрабатывать звонки.
Судя потому, что Вы это пишите, Вы не слишком понимаете в кооперации. Если это не так, то Вы должны были слышать о C10K и как проблема успешно решалась с использованием кооперативной многозадачности. Из примерно 10K условных соединений сдохнет скорее Астериск и pjsip в частности, а не external сервис на корутинах(при условии написания в кооперативном стиле).
Ваше принципиальное заблуждение — "корутина блокирует выполнение других задач", а смысл как раз противоположен. Корутина уступает контекст выполнения при простое/ожидании.
PreFork/etc в highload в 21-м году мало кто рассматривает, а вот асинхрон и событийный подход да, как Вы думаете почему?
Какие два цвета, о чем Вы...
Мне кажеться, что Вы путаете мягкое и теплое, в чем противоречия:
Вы считаете, что это НЕ нормально?
Такое впечатление, что Вы проецируете свои профессиональные комплексы прямо сюда. Ну не срастается у вас с ARI, так и черт с ним.
Прочитайте мой пост, я там более чем доходчиво высказал свое мнение про ARI и иже с ними.
Откуда Вы вообще взяли все эти фантазии, где упоминалось об — "вам нужно все начать сначала и написать с нуля". И вообще, такое впечатление, что вы не слишком поняли то что я пытался донести своими коментариями.
Что ж, очень жаль
А Вы видимо агетирует за стагнацию, как было написанов 2000-ых так и шпарим дальше.
Без развития любой проект обречен в лучшем случае на безвестность. А развитие, в свою очередь, предполагает некоторое проектирование, а не тяп ляп и в продакшен.
Но кто я такой чтобы говорить об этом.
Он не плох, он не так хорош как Вы ожидаете/хотите.
Уже давно агитирую за упрощение процесса "пищеварения" для астера, астер уже не торт и с каждым новым релизом это проявляется все ярче и красочней.
Один из способов — это упростить астеру жизнь, сделать из него медиа-хаб, простые примитивы(answer/hangup/redirect/bridge/etc), а логику и телодвижения выносить на сторонние сервисы.
Астериск уже давно готов к интеграционным решениям, ARI/FastAGI/etc.
Такие вещи, как в посте, реализовываются при таком подходе вообще прозрачно и без каких нибудь умственных страданий.