Node.js в чем профит делать все async?

в чём профит использовать этот инструмент там, где не нужна асинхронность?

Скажите, пожалуйста, а где тогда она вообще нужна?

А если эти три запроса надо сделать для десяти тысяч пользователей, создашь десять тысяч потоков?

Вы так говорите будто 10к запросов это так много.

Так если делать всё async там потоков будет минимум 10к, нет?

Нет, там будет потоков столько сколько у тебя ядер

минимум будет 1 поток

Тогда профит в чем, если всё равно в итоге все синхронно в 1 поток?

Тогда профит в чем, если всё равно в итоге все синхронно в 1 поток?

В том, что жабоскрипто схватится еще за 10к соединений, пока будет пытаться раскидать пул запросов к БД.

Это ладно, пусть хватается за соединения. Для доступа к субд какой профит пилить портянку из коллбеков, если раньше она от этого всё равно не освободится?

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

и сдаётся мне, синхронизировать там не так сложно

Не сложно, но такие костыли вымораживают даже меня.

до ноды, чтобы писать async нужно было три высших образования

Вот не принято тут хвалить решетку, но в ней и до ноды все писалось очень удобно и легко.

google://user threads

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

Не совсем так. До ноды писали m:n или 1:n тредами, поэтому до появления nginx, например, oops proxy (использовался вместо nginx) на этих ваших линуксах не мог работать (он как раз сотни тысяч тредов создает), но в те времена в моде были солярка и бсд, и всё было ок.

Нода однопоточная, ну, снаружи, если подвесишь мейнлуп тормозить будет у всех.

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

не, ну треды это совсем не об этом, вообще другой уровень. были гринлеты например, в питоне был gevent.

Нода однопоточная, ну, снаружи, если подвесишь мейнлуп тормозить будет у всех.

Печально, однако. Я думал, всё намного лучше будет.

Да, конечно, но их тогда обычно использовали на задачах, на которых сейчас используют асинхронщину.

А что ты хотел? Многопоточку пилить гемор, а в браузере она не нужна никому.

Ну, можно же, при желании, на уровне v8 создать несколько экземпляров vm, например, и распихать их по тредам. А то так получается, что если у меня будет какой-то жирный кусок js кода, который что-то там обрабатывает, то все будут стоять и ждать его. И зачем так упарываться по одной истинно верной архитектуре, а не сделать инструментов, чтобы люди сами могли сделать, как хотят?

В ноде там еще не релизнули сборку с async/await?

И зачем так упарываться по одной истинно верной архитектуре

ты Райана Дала то вспомни, когда он её бегал презентовал — это же школьник, нашел, что он уехал в Бруклин для того, чтобы стать «professional hipster»
https://www.youtube.com/watch?v=ztspvPYybIY

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

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

Ну и можно забить на то что запросы к бд тормозят, за то можно показывать какой отзывчивый сайт и как быстр он может показать юзеру анимашку "ждите".

ХЗ. Там есть какие-то либы с async костылями, но меня уже всерьёз беспокоит однопоточность.

в общем представлении так

этот жирный кусок уносят в асинхронщину

Перестал понимать. Т.е. если клиент посылает http запрос, колбек поедет в async? Или это просто делают опционально?

в феврале с версии 7.6 async/await доступен без флагов.

три запроса к субд один за другим, потом что-то обработать и выдать, в чем профит асинхронности?

В экономии серверных ресурсов :-) Образно говоря, *один асинхронный однопоточный сервер* может служить фронтом для нескольких многотрэдовых/многопроцессных серверов СУБД :-)

Ты путаешь асинхронность и параллельность.

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

Простой ответ на твой вопрос - да.

Тебе во первых нужно понять есть один поток, он выполняет event loop, в event loop попадают разные io операции и другие события. Когда ты запускаешь программу, она выполняется последовательно и если нет задач для event loop она просто завершится. Если есть асинхронным задачи типа ввода-вывода, событий, таймаутов и тому подобное, то event loop становится на ожидание этих событий и при их наступлении исполняет соответствующие коллбеки. Ты не можешь написать чистый асинхронный тяжелый расчёт в том же event loop. Потому, что если коллбек словил длинную не асинк операцию, то другие события не исполняться, пока он не отдаст управление в event loop.

Ты все в кучу свалил.

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

Без тредов (или аналогов) так не может никто. Либо ты используешь треды под реально синхронные функции, либо используешь продвинутую химию, которая позволяет коду ВЫГЛЯДЕТЬ синхронным.

поэтому надо делать коллбеки. Правильно понимаю?

Не правильно. Того же эффекта ты можешь добиться при помощи генераторов или async/await. Код будет выглядеть вполне синхронным.

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

Безотносительно ноды, async имеет смысл чтобы выразить в коде, что задача по своей постановке асинхронна - то есть может выполняться независимо от других. Как оно сработает внутри - при хорошей реализации не должно волновать: по крайней мере не хуже чем синхронно, а вероятно лучше.

три запроса к субд один за другим, потом что-то обработать и выдать, в чем профит асинхронности? Все равно надо ждать, пока это всё выполнится, зачем делать все принудительно асинхронно

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

Это значит, что очередной запрос по идее к БД не подвесит весь сервер и сможет принимать другие запросы в том числе и к БД, возможно более короткие.

Если такого в ноде нет, то профита в том действительно мало. Но как мне показалось при беглом ревью, такое должно быть или планируется судя по событийности, например вызова connect к БД т.к. то одна из основных фич, представляющих практический смысл.

В случае когда надо сделать три запроса к субд один за другим, потом что-то обработать и выдать, в чем профит асинхронности?

В возможности начать работать (силами того же потока) с чужими запросами пока ждём ответа от СУБД?

В возможности начать работать с чужими запросами пока ждём ответа от СУБД?

Для этого есть корутины даже в C++ boost.

Дык он спрашивал про без оберток. Ну типа как в пыхе, когда надо увеличивать fcgi-пул потому что занятые процессы простаивают.

Безусловно. Но вопрос же вроде касался преимуществ асинхронности, а не её реализаций?

Без тредов (или аналогов) так не может никто.

Erlang может. В MacOS Classic компилятор код на C и Pascal в кооперативную многозадачность компилировал.

Дык это именно видимость синхронности, с правильно оформленными системными вызовами. Кто заранее озаботился - положил корутины под капот. Остальным остается указывать в более явном виде - либо дергая ручками, либо через async/await.

Если ты синхронный фибоначи напишешь, корутины не помогут.

портянку из коллбеков

await и твои волосы будут мягкими и шелковистыми

раньше она от этого всё равно не освободится?

База раньше ответ не вернёт, а нода в этом же треде за время, пока база думает, успеет обработать ещё несколько запросов. Ну или начать обрабатывать.

А то так получается, что если у меня будет какой-то жирный кусок js кода, который что-то там обрабатывает, то все будут стоять и ждать его.

Именно из-за этого запускают несколько процессов ноды и всё становится ок.

Потенциально долгие вычисления в треде веб-сервера ни на одном нормальном продакшне не делают и с тредами, если что. Независимо от языка.

И да, нода была модной пока не появился golang.

th3m3 с тобою не согласен.

И да, нода была модной пока не появился golang.

Ага. Посмотри количество вакансий по Go в веб-сегменте и по node.js. Даже если посмотреть все Go вакансии, их будет намного меньше, чем node.js.

Интересно твое мнение по сабжу.

В контексте данной задачи, не вижу ничего плохого в том, если это будет занимать то же время. Мы можем выполнять какие-то другие действия, пока действие с БД будет завершено. Пусть оно будет висеть в ожидании, если на то пошло. Плохого в этом ничего нет. Да и раньше все кричали - «Асинхронный веб! Вот оно будущее!». Вот оно. Получайте :) Чего теперь задумываться? Работает, да и ладно. Ещё один подход, паттерн. А почему бы и нет? Костыли можно увидеть везде. В любом подходе. Для кого-то они будут откровением, а для кого-то костыли.

А что касается пользователя, тут вообще почти всегда всё достаточно быстро происходит, он даже не успевает задуматься и получает результат. Собственно, проблемы то и нет.