Node.js: где лучше, а где лучше не

что именно не нужно?

node.js по *заявленной* идее, если бы её реализовали, хорош был бы возможностью написать следующее:

sql(«запрос 1», когда будут поступать данные выполнить function())
sql(«запрос 2», когда будут поступать данные выполнить function())
считать_с_харда_данные(«файл», когда будут поступать данные выполнить function())

то есть выполняются sql,sql,считать_с_харда_данные, а function() выполняются «когда-то потом», когда придут данные, в последовательности поступления данных. может сперва файл считается, а может «запрос 2». и во время простоя, пока данные не пришли, может что-то ещё исполняться.

НО В NODE.JS ЭТО ЭМУЛИРУЕТСЯ, этого нет в реальности и врядли когда-то будет.

green threads - это «виртуальный параллелизм», читайте вики. то есть процесс эмулирует параллельность, по-очереди запуская функции внутри себя. поскольку по идеологии никогда(!) не будут исполняться две функции одновременно, то перейти от этого к параллелизму нельзя - нужны будут защёлки, не позволяющие функциям одновременно менять данные в одной и той же переменной, а этого идеология не позволяет.

native threads - это реальный параллелизм. один процесс=один процесс.

green processes - это erlang. нечто похожее на green threads, но с защелками, блекджеком и шлюхами. если копать вглубь то это *совсем* не green threads. потому и может выполняться параллельно и даже параллельно на кластере машин.

> green processes ... но с защелками

а зачем нужны встроенные защелки? Можно же фреймворком реализовать, и пихать только когда действительно нужно

А если вфигачить их в язык, так и до blocking api добраться недалеко, всего один шаг: надо сказать что два вызова api не могут выполняться одновременно ;)

этого нет в реальности

а в чем «реальность»? Два гига, два ядра, четыре процесса одновременно, и эмуляция 100500 процессов поверх них любыми доступными способами.. есть еще какая-то реальность?

> что именно не нужно?

Все эти параллелизмы.

НО В NODE.JS ЭТО ЭМУЛИРУЕТСЯ, этого нет в реальности

и врядли когда-то будет.

Что-то я не врубляюсь, что значит эмулируется ? Это обычные callback, что тут можно эмулировать?

green threads

native threads

green processes

читайте вики

Спасибо, читать не буду, уже давно всё прочитал, нахрена вы об этом здесь рассказываете? Это же не вики.

> Два гига, два ядра, четыре процесса одновременно, и эмуляция 100500 процессов поверх них любыми доступными способами.. есть еще какая-то реальность?
не видел этого на node.js, на erlang - видел. неужто сделали?

фреймворком, наверное, можно, но я бы, наверное, очковал пользоваться таким фреймворком.

запустить несколько процессов ноды (не важно где), и общаться между ними каким-нибудь memcached. Виртуализация ложится на ОС. Не? Медленно?

тогда какая разница - node это или v8cgi. а второму я доверяю больше. вот если бы нода запускала callback в виде green processes...

> тогда какая разница - node это или v8cgi

Полностью не блокирующий ввод/вывод и масса профита с этим связанная? Всякие параллелизмы только снижают производительность.

Так и делают обычно. По процессу на ядро и сессии в редисе. Для стандартных вебовских задач. Чайлдовые процессы тоже можно лепить, но это реже надо.

А разница, дружище, в том, что cgi по скорости сольет минимум в 2 раза. Такие у него гены.

Ваш КО

НО В NODE.JS ЭТО ЭМУЛИРУЕТСЯ, этого нет в реальности и врядли когда-то будет.

Мне кажется, ты не знаешь матчасти.

Забавно, но ведь Володя пока единственный в этом треде, кто аргументированно впрягся за эрланг и раскритиковал ноду ;)

кто аргументированно впрягся за эрланг

Слава яйцам в оппосте не был упомянут hunchentoot.

раскритиковал ноду

Увы, совсем не конструктивно.

> аргументированно впрягся за эрланг

Вроде бы уже договорились, что сравнение Erlang и Node.js лишено практического смысла? То, что erlang-разработчики воспринимают успехи Node.js болезненно не означает, что Node.js и Erlang являются конкурентами.

> Слава яйцам в оппосте не был упомянут hunchentoot.

Предлагаю добавить Mongrel2.

Mongrel2.

Тогда, в обязательном порядке, приползет питоновский гадюшник всем составом.

> http://archimag-dev.blogspot.com/2011/02/restas-mongrel2.html

archimag

ох

> http://archimag-dev.blogspot.com/2011/02/restas-mongrel2.html

Тогда лучше брать такую ссылку: http://archimag.lisper.ru/permalink/posts/40bf92e3000dba30e3ccfd8d4d94d448d61...

> Ваш КО
а пристваку (fast)cgi не заметил? или думаешь что оно тоже недостаточно быстрое?

Поразите меня. Скажете, что это не пул интерпретаторов в памяти, как в пыхе, а постоянно работающее приложение, как в ноже.

Как в ноде, жабе, и куче других полноценных платформ приложений :)

v8cgi работает как (на выбор):
cgi
fastcgi
mod_v8cgi

Если там такой же fcgi как в пыхе -не нужен. Пруфы на доки, где написано что приложение в памяти висит. Или сольет в 2 раза :)

Ps. Суда по датам, fcgi там сырой и никакой.

> v8cgi

Так что там с неблокирующим I/O?