Вот уж действительно. Наверное именно поэтому 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.
Такие вещи, как в посте, реализовываются при таком подходе вообще прозрачно и без каких нибудь умственных страданий.
Почему то уверен, что вы их и не увидите, по крайней мере на нагрузке среднего/малого офиса. Но плохой стиль проектирования ни куда не денешь, в будущем аукнется.
Объективно, по возможным причинам будущих проблем выше отписался.
Опять же есть сомнения по поводу «красоты» и правильности итоговых данных в CDR.
Не сомневайтесь, все там как и требовалось, одна запись:
Как то давно, еще на opennet'ах или linux.org'ах, высказал свое личное мнение, что подпускать индивидуума к PC нужно строго по документам aka правам на управление PC. Естественно, если хочешь кодить/фронтэндить/геймдевить и вообще работать в IT и с PC, то будь добр отучись, cдай на права, отъезди набор часов с инструктором, ну вы поняли аллегорию… Сейчас это крамола актуально как ни когда.
А то что касается корреляции дистрибутива и знаний, мне кажется она обратно пропорциональна. То есть, люди жаждущие знаний, кастомизации своей рабочей системы под себя и просто увлеченные процессом, вот такие люди выбирают Gentoo/Arch/Slackware или даже FreeBSD/OpenBSD/NetBSD и уже в процессе этого выбора приобретают столь нужные/важные знания.
Лично для себя остановился на voidlinux — потому что linux, потому что без systemd, потому что паритет между компилять и репозиторием.
Бытует мнение, что философия, между прочим — это мать математики/физики.
Если уж на то пошло, то я не против Redirect'а, я против связки Redirect/MASTER_CHANNEL и мне кажется очевидным почему.
То, что касается способа решения, то вам как, как у вас или как надо? Если как у вас, то самый простой и красивый вариант, без лишних каналов и засирания CDR — это эмуляция peer'а
Вы меня конечно извините, но, если это в качестве примера как можно, то зачем это здесь, это же могут увидеть "дети" и потом попробуй отучи их так делать.
А если серьезно:
Каналы типа Local это зло, есть же куча способов завернуть звонок на контекст
ChannelRedirect/MASTER_CHANNEL это ж ад адский
Астериск уже давно готов к интеграционным решениям и выносу логики обработки звонков на сторонние сервисы и именно по этому данная задача кажется слегка надуманной
P.S. Еще раз убеждаюсь что PJSIP ведет нас всех куда то не туда, ну или не теми путями ...
Я полагаю могу ваше сообщение переадресовать DrPass, типа все то же самое, по поводу sdr-трансивера и того что производитель не удосужился создать бинарный пакет под него?
Согласен на все 100%. Пример из жизни, usb сканер Be@rPaw 1200CU, на коробке написано Windows 7 Ready, типа воткнул, подождал чутка и сканируй в свое удовольствие, и так оно и есть.
Но вот под Win 10 почему то уже нет. Не, конечно можно подсунуть и из 7-ки и пошаманить можно, но это уже ни чем не лучше того же юникс-стайл'а.
Да да да, слышали, знаем. К примеру KB5000808/KB5000802, ну ни как не хочет откатываться через графический интерфейс, они видите ли являются обязательным по мнению MS. Ну ни чего, мы же через консоль его можем откатить wusa /uninstall ...., блин блин блин — это же как в Linux получается, а нет, оно и так не удаляется. Бедные бабушки и не опытные пользователи, так и сидят с синим экраном.
Одна на звонок, одна на hangup hook, одна на gosub в Dial. Ничего криминального и удивительного как по мне =). Или должно было быть что-то еще?
OK, тогда почему на не существующий экстеншен в этом контексте записей уже 4-е. Стоп, по такой логике на каждое application будет gosub. И обратите внимание, что в примере нет Dial.
Да и это все не важно — такое дерганье это же файловая операция + выполнение.
сориентируйте по количеству пиров на единицу астериска
Несколько десятков машин, несколько миллионов в день…
Но это правда, мамой клянусь, есть такой сервис в природе.
А когда это в нашей дискуссии передергивание стало заходит как аргументация? Че так можно было…
Я вам про теплое, Вы мне про мягкое. Не зачет.
Я Вас правильно понимаю, что агитация(то что вас и подорвало изначально) за 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.
Такие вещи, как в посте, реализовываются при таком подходе вообще прозрачно и без каких нибудь умственных страданий.
Почему то уверен, что вы их и не увидите, по крайней мере на нагрузке среднего/малого офиса. Но плохой стиль проектирования ни куда не денешь, в будущем аукнется.
Объективно, по возможным причинам будущих проблем выше отписался.
Не сомневайтесь, все там как и требовалось, одна запись:
Да абсолютно так же, меняем канал с chan_sip на pjsip и впихиваем PJSIP_DIAL_CONTACTS везде где нужно.
Нет, не правильно. Wait тут нужен лишь для originate, что бы он был доволен. Originate нужно второе плече, с таким же успехом мы можем задать:
Вся магия в контексте default/local.
Да практически всем:
Зато в моем примере имеем чистый, линейный диалплан с синхронным выполнением и без кучи телодвижений.
В качестве примера и по мотивам автора:
А вообще, этот таск лучше реализовывать сооовсем по другому, причем кардинально ...
Автору уважуха, согласен на все 100%.
Как то давно, еще на opennet'ах или linux.org'ах, высказал свое личное мнение, что подпускать индивидуума к PC нужно строго по документам aka правам на управление PC. Естественно, если хочешь кодить/фронтэндить/геймдевить и вообще работать в IT и с PC, то будь добр отучись, cдай на права, отъезди набор часов с инструктором, ну вы поняли аллегорию… Сейчас это крамола актуально как ни когда.
А то что касается корреляции дистрибутива и знаний, мне кажется она обратно пропорциональна. То есть, люди жаждущие знаний, кастомизации своей рабочей системы под себя и просто увлеченные процессом, вот такие люди выбирают Gentoo/Arch/Slackware или даже FreeBSD/OpenBSD/NetBSD и уже в процессе этого выбора приобретают столь нужные/важные знания.
Лично для себя остановился на voidlinux — потому что linux, потому что без systemd, потому что паритет между компилять и репозиторием.
Бытует мнение, что философия, между прочим — это мать математики/физики.
Если уж на то пошло, то я не против Redirect'а, я против связки Redirect/MASTER_CHANNEL и мне кажется очевидным почему.
То, что касается способа решения, то вам как, как у вас или как надо? Если как у вас, то самый простой и красивый вариант, без лишних каналов и засирания CDR — это эмуляция peer'а
Естественно подгоняем контекс default(именно туда такой звонок и придет)
Если же вдруг с default проблемы то делаем пира, скажем local
И уже в контексте local делаем все безобразия которые нам нужны.
Вот как то так ....
Вы меня конечно извините, но, если это в качестве примера как можно, то зачем это здесь, это же могут увидеть "дети" и потом попробуй отучи их так делать.
А если серьезно:
P.S. Еще раз убеждаюсь что PJSIP ведет нас всех куда то не туда, ну или не теми путями ...
Я полагаю могу ваше сообщение переадресовать DrPass, типа все то же самое, по поводу sdr-трансивера и того что производитель не удосужился создать бинарный пакет под него?
А че, заморочки производителя и т.д и т.п.
Согласен на все 100%. Пример из жизни, usb сканер Be@rPaw 1200CU, на коробке написано Windows 7 Ready, типа воткнул, подождал чутка и сканируй в свое удовольствие, и так оно и есть.
Но вот под Win 10 почему то уже нет. Не, конечно можно подсунуть и из 7-ки и пошаманить можно, но это уже ни чем не лучше того же юникс-стайл'а.
Да да да, слышали, знаем. К примеру KB5000808/KB5000802, ну ни как не хочет откатываться через графический интерфейс, они видите ли являются обязательным по мнению MS. Ну ни чего, мы же через консоль его можем откатить wusa /uninstall ...., блин блин блин — это же как в Linux получается, а нет, оно и так не удаляется. Бедные бабушки и не опытные пользователи, так и сидят с синим экраном.
OK, тогда почему на не существующий экстеншен в этом контексте записей уже 4-е. Стоп, по такой логике на каждое application будет gosub. И обратите внимание, что в примере нет Dial.
Да и это все не важно — такое дерганье это же файловая операция + выполнение.