Единственный контекст, под которым я обобщаю эти 2 понятия, — это вынос тяжелых задач за пределы основного event-loop. Да, эти threads-a-gogo можно считать решением. Хотя я не вижу активное развитие проекта. Код выглядит все также плохо.
Вывод для меня: да, возможно. threads-a-gogo — хороший вариант. Однако, почему-то он не кажется нативным для node.js Еще одно расширение, написанное на C/C++
Когда функционал базового V8, Fibers, Threads-a-gogo, Async объединится в единое решение и, что не менее важно, появится для этого хороший api — я смогу считать Node.js, как платформу, зрелой. Но это лишь будет достижением уровня JVM .NET Go и, может, чего-то другого…
Воркеры, упомянутые Вами, похоже на те, что составляют worker queue. Так?
Задача в 10-20 мс достойна выделенной очереди в таком случае?..
«принцип построения асинхронных однопоточников» — даже звучит не очень. эту однопоточность я и подвергаю критике.
Итак, для выноса cpu-intensive задач (еще довольно непонятно когда задача в node.js приобретает этот статус) возможны варианты:
1. worker queue (здесь я подразумеваю и ответ после обработки)
2. fibers — насколько я узнал это расширение возможностей V8. На 80% написана на С/С++. То, небольшое количество кусочков кода, приведенных в документации выглядят, мягко говоря, неуклюже. Сомневаюсь, что большинство вообще его использует.
О Java надо говорить не как о языке, а подразумевать JVM, как платформу со Scala, Clojure… Которые могут быть более элегантны, удобны и менее многословны, чем Node.js
И каким образом обычно происходит общение с этой внешеней программой? Система от этого перестает быть проще.
> «В случае ноды можно забыть про многопоточность»
Я люблю многопоточность. Забыть про локи, синхронизацию и т.д. можно и в других, более лучших средах.php
Я программирую под JVM на Scala. Наша небольшая компания ни разу не энтерпрайз, я не посещаю семинары от Microsoft/Oracle, и я не усатый дядька.
Если бы заголовок статьи был «Чем node.js лучше php», я бы ни сказал ни слова. Но не надо критиковать тут неповоротливость платформ JVM и .NET. Реализация событийной модели на них гораздо лучше. Верю, что и с Go дела обстоят также.
> Так что другие клиенты просто пойдут на другие воркеры.
Как они пойдут?.. Допустим, это будет round-robin…
Как один нод узнает, что другой выполняет cpu-intensive work и возьмет работу на себя?
Конечно, прирост производительности будет. Но ответы клиентам в рамках одного воркера будут задержаны.
Вы правда не согласны, что модель пула тредов внутри воркера более эффективна, чем однопоточная сущность nodejs?
Я и сам поклонник async/non-blocking моделей, но не думаю, что это лучше делать на nodejs. Алетернатив достаточно…
не цепляйтесь конкретно за парсинг. Все, что я хочу сказать — это то, что любая cpu-intensive задача тормозит работу всего процесса (например, задерживает ответы клиентам)
В которых также критикуется однопоточность nodejs.
По первой ссылке: парсинг 15mb json — 1.5 секунды. В более реальном примере пусть будет 150kb — 15ms.
На эти самые 15 ms будут задержаны все ответы клиентам. И не важно сколько в таком случае nodejs будет поддерживать одновременных подключений, чем очень гордится. Я не вижу возможности отделить пул или хотя бы один поток для обслуживания событий запрсов-ответов клиентам. Даже модель кластера из воркеров не будет достаточно эффективна при подходе «по потоку на воркер».
Тема кластера nodejs затрагивается по второй ссылке.
"...Using Cluster looks simple, but if you’re a conscientious programmer, you now have a few things to worry about. For example “Forking a new worker when a death occurs” or “Monitoring worker health using message passing”. "
И после всего, модуль Cluster — экспериментальный!
И о какой зрелости проекта, упоминаемой в статье можно вести речь?..
Согласен. Тем не менее, привзязанность воркера к одному потоку — это уже верхняя планка.
Действительно ли в мире nodejs вообще нет (не предусмотрено/никогда не используются) блокирующих контекст (текущий поток) вызовов? Потому, как я понимаю, учитывая однопоточность, один такой вызов функции может заблокировать весь eventloop внутри воркера.
«A single instance of Node runs in a single thread. To take advantage of multi-core systems the user will sometimes want to launch a cluster of Node processes to handle the load.»
Статус — Experimental (!)
Мне кажется, код по ссылке для запуска кластера выглядит довольно неуклюжим.
В статье был пример использования async для параллельного выполнения задач. Пусть это будут запросы к бд, например. Чтобы был прирост производительности от параллельного выполнения, все функции должны быть асинхронные и неблокирующие процесс. Даже с учетом того, что событийная модель реализована во всех драйверах (самый лучший случай!) для nodejs, все эта параллелизация будет выполняться в рамках одного процесса (узла кластера).
… Now we're joining the Gmail team to accomplish a bigger vision — one that we think we can better achieve with Google.
...Full speed ahead!
—
Dom Leca, CEO
Есть уже опыт применения на своих реальных проектах?
Мы в Томском Политехническом начинали строить RPC-API на Akka2 + Google Protobuf. Добивались довольно хорошей параллелизации: на девелоперской машине htop показывал почти равномерную загрузку всех 8ми ядер на составной запрос.
Но позже выяснилось, что для нашей специфики больше подходило Twitter Finagle + Thrift. Многие возможности Akka не использовались — все сводилось к асинхронным посылкам сообщений типа ask, редко one-way.
Своим комментарием я по большей части делал акцент на мехазме описания soap — сервиса — то есть написании wsdl. Но что касается сообщений — можно взять просто Thrift, Protobuf или др. за основной механизм сериализации/десериализации.
Вывод для меня: да, возможно. threads-a-gogo — хороший вариант. Однако, почему-то он не кажется нативным для node.js Еще одно расширение, написанное на C/C++
Когда функционал базового V8, Fibers, Threads-a-gogo, Async объединится в единое решение и, что не менее важно, появится для этого хороший api — я смогу считать Node.js, как платформу, зрелой. Но это лишь будет достижением уровня JVM .NET Go и, может, чего-то другого…
Воркеры, упомянутые Вами, похоже на те, что составляют worker queue. Так?
Задача в 10-20 мс достойна выделенной очереди в таком случае?..
«принцип построения асинхронных однопоточников» — даже звучит не очень. эту однопоточность я и подвергаю критике.
Итак, для выноса cpu-intensive задач (еще довольно непонятно когда задача в node.js приобретает этот статус) возможны варианты:
1. worker queue (здесь я подразумеваю и ответ после обработки)
2. fibers — насколько я узнал это расширение возможностей V8. На 80% написана на С/С++. То, небольшое количество кусочков кода, приведенных в документации выглядят, мягко говоря, неуклюже. Сомневаюсь, что большинство вообще его использует.
К C# я мало отношения имею. Но частенько пробегают статьи про его асинхронные механизмы.
Тут и комментарий есть
habrahabr.ru/post/191646/#comment_6657790
О Java надо говорить не как о языке, а подразумевать JVM, как платформу со Scala, Clojure… Которые могут быть более элегантны, удобны и менее многословны, чем Node.js
> «В случае ноды можно забыть про многопоточность»
Я люблю многопоточность. Забыть про локи, синхронизацию и т.д. можно и в других, более лучших средах.php
Я программирую под JVM на Scala. Наша небольшая компания ни разу не энтерпрайз, я не посещаю семинары от Microsoft/Oracle, и я не усатый дядька.
Если бы заголовок статьи был «Чем node.js лучше php», я бы ни сказал ни слова. Но не надо критиковать тут неповоротливость платформ JVM и .NET. Реализация событийной модели на них гораздо лучше. Верю, что и с Go дела обстоят также.
> Так что другие клиенты просто пойдут на другие воркеры.
Как они пойдут?.. Допустим, это будет round-robin…
Как один нод узнает, что другой выполняет cpu-intensive work и возьмет работу на себя?
Конечно, прирост производительности будет. Но ответы клиентам в рамках одного воркера будут задержаны.
Вы правда не согласны, что модель пула тредов внутри воркера более эффективна, чем однопоточная сущность nodejs?
Я и сам поклонник async/non-blocking моделей, но не думаю, что это лучше делать на nodejs. Алетернатив достаточно…
zef.me/4561/node-js-and-the-case-of-the-blocked-event-loop
bitcartel.wordpress.com/2012/05/22/the-node-js-cpu-blocking-thing/
В которых также критикуется однопоточность nodejs.
По первой ссылке: парсинг 15mb json — 1.5 секунды. В более реальном примере пусть будет 150kb — 15ms.
На эти самые 15 ms будут задержаны все ответы клиентам. И не важно сколько в таком случае nodejs будет поддерживать одновременных подключений, чем очень гордится. Я не вижу возможности отделить пул или хотя бы один поток для обслуживания событий запрсов-ответов клиентам. Даже модель кластера из воркеров не будет достаточно эффективна при подходе «по потоку на воркер».
Тема кластера nodejs затрагивается по второй ссылке.
"...Using Cluster looks simple, but if you’re a conscientious programmer, you now have a few things to worry about. For example “Forking a new worker when a death occurs” or “Monitoring worker health using message passing”. "
И после всего, модуль Cluster — экспериментальный!
И о какой зрелости проекта, упоминаемой в статье можно вести речь?..
Действительно ли в мире nodejs вообще нет (не предусмотрено/никогда не используются) блокирующих контекст (текущий поток) вызовов? Потому, как я понимаю, учитывая однопоточность, один такой вызов функции может заблокировать весь eventloop внутри воркера.
«A single instance of Node runs in a single thread. To take advantage of multi-core systems the user will sometimes want to launch a cluster of Node processes to handle the load.»
Статус — Experimental (!)
Мне кажется, код по ссылке для запуска кластера выглядит довольно неуклюжим.
В статье был пример использования async для параллельного выполнения задач. Пусть это будут запросы к бд, например. Чтобы был прирост производительности от параллельного выполнения, все функции должны быть асинхронные и неблокирующие процесс. Даже с учетом того, что событийная модель реализована во всех драйверах (самый лучший случай!) для nodejs, все эта параллелизация будет выполняться в рамках одного процесса (узла кластера).
Есть способ использовать ресурсы всех ядер?..
Слова их CEO идут вразрез с Вашей напуганностью.
Это как же второй никому не нужный кириллистический домен будет способствовать продвижению культуры?!
Мы в Томском Политехническом начинали строить RPC-API на Akka2 + Google Protobuf. Добивались довольно хорошей параллелизации: на девелоперской машине htop показывал почти равномерную загрузку всех 8ми ядер на составной запрос.
Но позже выяснилось, что для нашей специфики больше подходило Twitter Finagle + Thrift. Многие возможности Akka не использовались — все сводилось к асинхронным посылкам сообщений типа
ask, редкоone-way.Возможность записи в navigator.battery.level была бы очень интересна… :)