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

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

Она нужна везде где не нужно ждать результата сразу, пока ты будешь делать 1 http запрос на сервак, я сделаю 10 и буду ждать ответ попутно их обрабатывая один за другим. Если не нужна асинхронность - не используй вот и весь ответ.

Не правильно.

А выше говорили, что правильно.

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

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

Если надо, этим отдельно занимается специальный сервер, а веб только снэпшоты состояний может отдавать, например.

Я-то тут при чем :)? Спрашивай тех кто говорил.

А если сильно надо?

Запускаешь тред/процесс воркера, делающего вычисления. Веб-сервер сообщает статус (по возможности через вебсокет) либо просто говорит, что задача запущена. Всё.

Ну или считает сразу на всех какой-нибудь Apache Storm и кладёт туда, откуда веб-сервер потом может забрать.

Что-то сложна.

То есть предлагаешь, по сути, стравливать участников треда?

В жирных фреймворках обычно есть средства, чтобы делать это парой строк кода.

Твои вопросы про ноду становятся все более содержательными.

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

И тебе совсем не мешает что http сам по себе синхронный?

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

http-сервер может обрабатывать одновременно множество клиентов. Можно заводить на каждого отдельный поток, который будет 99% времени ожидать ответов от БД, ФС и т. п., но при этом отнимать ресурсы ОС на своё существование. А можно в одном потоке быстро послать запрос к БД, зарегистрировать callback на ответ, а самому перейти к обработке запроса от следующего клиента.

(А)синхронность сервера тут не интересна.

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

Я к тому что асинхронные запросы http/1 внутри по сути всё равно синхронны. Может быть удобная техника, но прорыва по скорости не даст.

http-сервер может обрабатывать одновременно множество клиентов.

Это верно, все знают 500 bad gateway. Толку то?

Ты просто не знаешь, что такое медленный запрос и как ими можно «уложить» синхронные серверы, в том время как асинхронным никаких проблем это не создаст.

Речь шла про асинхронность на клиенте, при чем тут архитектура сервера, алё!

А раз про клиент ну тогда слушай.

И тебе совсем не мешает что http сам по себе синхронный?

Во первых это не совсем верно, так как существует HTTP pipelining.

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

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

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

Эммм, чем он синхронный то? Если я послал запрос и ожидаю ответ.

Golang забыл ;)

oops proxy

В свое время, у упса в самом коде было захоркожено 65536 одновременных соединений. При первой же маломальском DDoS и быстром «аудите» кода сразу стало понятно, что такой за софт oops proxy и где ему место.