Концептуальные вопросы работы Node.js

[chin-chin]

Собственно пришлось по работе коснуться вопроса асинхронной работы с данными, совершенно случайно вышел на Node.js, т.к. интересы лежат несколько в другой плоскости. Теперь же хочется понять следующее.
Сперва наводящий вопрос, ответ на который может все разрешить:
Где-нибудь можно посмотреть диаграмму работы механизма Node.js?
Что не понятно, буду говорить не всегда точным языком, тапками чур не забрасывать:
1) Я делаю приложение Hello world которое вешает колбэк на конкретный порт. Правильно я понимаю, что на него реагирует один mainloop - который я повесил и при одновременном обращении - параллелизма, и соответственно никакой диспечеризации запросов, не возникает - второй запрос будет ждать исполнения первого. Соответственно он возникает, если использовать кластер из нод, который и служит диспечером разных процессов main loop
2) Возьмем примитивную задачу парсинга ну очень большого файла XML. Требуется обеспечить параллельный парсинг, асинхронную проверку на ФЛК и запись значений в БД. Мне видится, что я делаю декомпозицию файла по некоторому алгоритму, отдаю эти части на съедение разным процессам, которые в свою очередь делают разбор и сохранение данных в БД, затем осуществляется синхронизация процессов, проверка на ФЛК( могут быть трудные случаи появления повторов в пределах одного XML), причем ФЛК заворачиваем в разные потоки, чтобы они параллельно исполнялись, синхронизируем результат и собственно формируем развернутый ответ по ошибкам, либо фиксируем изменения и даем позитивный ответ. Каким образом правильно работать с Node в таком случае? Да забыл сказать, что речь идет об асинхроне, соответственно делаются манипуляции и управление сразу возвращаются.
3) К вопросу №2 передача файла со стороны клиента и получение со стороны сервера. Правильно я понимаю. что есть механизм получения файла, его асинхронного сохранения в файловую систему. Вопрос в том как обеспечить последующую работу с файлом в Node в соответствии с п.2(механизмы, когда серверный Node становится клиентом относительно других нодов).
5) В какой момент осуществляется инициализация переменных и объектов. Обратил внимание на то, что во многих примерах подразумевается, что при каждом вызове колбэк функции создаются новые экземпляры объектов, старые при этом не уничтожаются(возможно зачищаются автоматом). Вопрос не праздный обратил внимание что при реализации таких примеров идет утечка по памяти с последующим обрушением приложения.

[nerv_]

https://learn.javascript.ru/nodejs-screencast

[chin-chin]

сабж

[MallSerg]

Спасибо, а своими словами никак?

Никак

На лицо явное непониманимание базовых концепций языка и как следствие неправильное использование возможностей.
для начала хотя бы бегло прочти.
https://ru.wikipedia.org/wiki/Node.js
Событийно-ориентированное программирование
Автоматное программирование
А в особенности где применяются и для чего служат данные концепции.

Если совсем на пальцах объяснять
то в задаче
1. полностью скачать большой файл от клиента
2. Разбить его на части с помощью какого то алгоритма
3. Обрабатывать полученные части в разных потоках
Использовать nodeJS глупо и даже вредно тот же PHP справится с такой задачей ни чуть не медленнее а кода писать придется в десятки а то и сотни раз меньше.

[Max Power]

chin-chin,

Предыдущие ораторы правы, для реализации таких вещей нужен некоторый solid knowladge по Ноде. Технологически такие вещи делаются просто, Нода для этого подходит.

MallSerg,

> Использовать nodeJS глупо и даже вредно тот же PHP справится с такой задачей ни чуть не медленнее а кода писать придется в десятки а то и сотни раз меньше.

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

В этом я недавно убедился лично, когда написал http-сервер, который ресайзит изображения на лету: https://github.com/i-erokhin/imconfl...aster/index.js . Суть в том, что тяжелые операции можно смело выносить в отдельные процессы, потому что накладные расходы на создание нового процесса, которых везде боятся, в данном случае уже роли не играют. В моем случае Нода порождает процесс и ждет пока он не отработает. А внутри процесса идет сверх-тяжелая операция пере-рендеринга растровой картинки. При этом Нода не занята, и может комфортно раздавать статику, напиример (лучше на входе повесить для этого nginx, но можно и не вешать иногда).

> 2. Разбить его на части с помощью какого то алгоритма
> 3. Обрабатывать полученные части в разных потоках

Не надо этого, просто создать процесс и скормить ему ВЕСЬ файл. Лучше, чтобы этот процесс умел все ядра юзать. Зачем потоки?

[chin-chin]

Ребята, спасибо за ответы.
MallSerg,
Язык это всего лишь средство выражения. Глобально все программы строятся в голове и только потом находят свою конкретную реализацию в конструкции конкретного языка. Соответственно, чтобы понять концепцию не надо знать все языки, достаточно говорить на одном и том же - русском. С пониманием все в порядке, материалом владею более или менее, то что коряво говорю на китайском не говорит о моем скудоумии
Max Power
Касательно процессов и потоков. Мне на данный момент критично меньшее использование ресурсов железа, т.к. под разбор могут попадать сотни тысяч файлов одномоментно, поэтому например та же dom модель нереальна, так же как бесконтрольной запуск процессов и потоков.
В том что я прочитал про Node смущает следующее:
1) Сам Node выполняется в одном процессе(кластер не берем). Вопрос как выполняются все асинхронные штучки платформы, например то же сохранение файлов? Они разделяют ресурсы процесса Node или под них создаются отдельные процессы со своими ресурсами?
2) Прелесть Node на мой взгляд именно в событийной модели - вешаются хуки и не тратится дополнительно время программиста(почти) на диспечеризацию асинхронного выполнения, если мы переходим в плоскость запуска отдельных процессов, то не понятно что дает платформа - тоже самое можно сделать гораздо проще и на классических языках Java/C#.

[Max Power]

> Сам Node выполняется в одном процессе(кластер не берем)

Потоке! В одном потоке на процесс, JS так был задуман изначально, поскольку JS в браузере приходилось делить процесс с кучей других вещей, включая конкретно рисовалку отрендеренного dom.

> Вопрос как выполняются все асинхронные штучки платформы, например то же сохранение файлов?

Сохранение файла - это вызов интерфейса операционной системы. Нода при этом физически с файлом не работает и свободна, в этом и фишка. При правильной организации Нода всего лишь жонглирует стримами, перекладывая стримы чтения в стримы записи (не всегда так получается, но в целом суть такая) - это копеечная операция.

> если мы переходим в плоскость запуска отдельных процессов, то не понятно что дает платформа - тоже самое можно сделать гораздо проще и на классических языках Java/C#.

Все так, все преимущества ноды будут сводиться к "просто я знаю ноду". В моем вышеупомянутом скриптике Нода лишь контролирует все сверху, самое критичное делает программа ImageMagick, написанная на C. И не надо бояться процессов, процесс - это основа философии Unix, процессы плохи только в контексте проблемы 10k соединений, в контексте тяжелых задач накладные расходы на создание процесса ничтожны.

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

Ну совсем одновременно смысла нет, для таких вещей существуют диспетчеры задач (очереди), Сelery например, есть клиент под Ноду: https://github.com/mher/node-celery (комрады возможно подскажут более Node-style диспетчер). Создаем очередь, забиваем туда задачи, контролируем выполнение, можем отключаться и подключаться снова (между http-запросами например). Главное - загрузить все ядра на 100%, для этого хватит одновременного выполнения всего нескольких задач.

> меньшее использование ресурсов железа

на 99% это будет зависеть от реализации самого парсера, как организовать работу этих парсеров и управление задачами - в контексте железа дело десятое.

[chin-chin]

Max Power, спасибо, вопросы еще остались, но дальше думаю нужна самостоятельное изучение и практика. Попутно посмотрел все скринкасты, дисперчеризация как и предполагал очень хорошая. Пока у меня понимание на уровне - хорошая штука, непонятно только зачем она мне сдалась, но чувствую, что у нее огромный потенциал в контексте масштабируемости. Работа Node по ощущениям хорошо ложится на сетевые(графовые) штучки, не хватает механизма внятной параллелизации (на уровне реализации) для управление пулами нод.
Еще раз спасибо.