> Думаю всё-таки как критерии эффективности стоит выбирать скорость, требовательность к ресурсам
Сколько это сэкономит или заработает денег вашему бизнесу?
Больше чем бизнес потратит на поиск следующего разработчика, который будет готов поддерживать гениальный, уникальный, сверхоптимизированный код?
Смысл в том, что мы хотим балансировать по другому алгоритму, а нода предоставляет только round robin. PM2 не панацея и скорее всего мы от него откажемся - это комбайн, который умеет намного больше чем нужно. Сейчас смотрим в сторону модуля luster
Тимур, я ждал Вас в этом таске =) Утечка памяти это к сожалению далеко не главное чего я опасаюсь в долгоживущих подпроцессах. Меня скорее волнует потеря локальной очереди RPC запросов внутри "воркера" (назовем его так). Не ответить на один запрос - не страшно, страшно не ответить еще на 10 только потому, что рядом с ними исполнился неугодный код. Как Вы поступаете в этой ситуации? Перепосылаете запросы в новый инстанс? Не создаете очередь внутри воркера? Или пытаетесь сделать воркер непадающим?
В данном случае идет миграция со старого API, которое и было реализовано подобным образом (JSX). От перехода на NodeJS со старой архитектурой уже будет профит, но я естественно понимаю, что использовать ноду подобным образом - это все равно что не превышать скорость на мотоцикле. Для меня предпочтительнее будет использовать неоднородный кластер с основным процессом в качестве балансера. Плюс переработка архитектуры с расчетом на скорое появление воркеров. Одна из основных проблем при подобной архитектуре - обработка ошибок - недопустимо имень непредсказуемую смерть у зависимых процессов в кластере, но думаю что промисы с легкостью решат эту проблему.
Благодарю за ваше мнение.
Rinat Mullayanov , "странно вообще почему такое поведение сделали" никто это поведение конечно же не планировал. В io.js есть открытый тикет связанный с этой проблемой, но пугают комментарии к нему "Да, исправлять надо, но только после введение WebWorkers". А WebWorkers это нефиговый так пулл реквест, ревью которого затянется еще надолго, или что хуже он будет выкачен в продакшн в сыром состоянии.
Rinat Mullayanov , я скорее соглашусь с высказыванием, что у nodejs нет большого брата, НО! Теперь у nodejs есть четкий цикл опенсурс разработки в рамках Node Foundation. А за сопровождением enterprise проекта (если бы сопровождение понадобилось), я бы конечно обратился в Strongloop.
Rinat Mullayanov, на strongloop я бы не стал надеяться как на большого брата. Ребята молодцы и имеют в своей команде сразу двух core nodejs разработчиков (Bert Belder и Ben Noordhuis), но основные их усилия сосредоточены именно на проекте loopback и вклад остальных участников strongloop в стабильность nodejs очень незначительный.
По поводу Node Inspector хочу только заметить, что действительно стабильного процесса отладки стоит ожидать только от node 0.10.* (в данный момент). В версии 0.12 приличная часть отладчика (собственно точка входа в него) была переписана с нуля, добавим к этому io.js который обеспечивает проблемы с C++ аддонами на Windows и вот уже запуск Node Inspector превращается в боль. Конечно все становится лучше со временем и например вчера я зарелизил зависимости, которые снимают большую часть вопросов по C++. Но например то, что процесс завершится с ошибкой если отключить от него отладчик, это жесткий баг со стороны nodejs.
Пожалуй я с вами не соглашусь. Есть два принципиально разных гит процесса: первый описан вами - делаем в дев ветке что заблагорассудится, в мастер отправляем как грязный мердж. Из плюсов: простота и скорость, из минусов отсутствие адекватной истории - все ваши коммиты в мастер называются 'Merge ...' и не несут никакой смысловой нагрузки, приходится хранить историю всех дев веток, чтобы понять прошлое проекта. Вариант второй: отправлять в мастер только чистые изменения через --ff-only. Из плюсов: делим проект на меньшие логические части, удобнее делать bisect, по истории коммитов мастера можно хоть change.log составлять. Из минусов - это очень кропотливый путь, не подходит для сверхдинамичных проектов и новичков, мы не можем себе позволить коммит типа 'Fix typo'. Но способность мыслить законченными микрокоммитами очень помогает.
Сколько это сэкономит или заработает денег вашему бизнесу?
Больше чем бизнес потратит на поиск следующего разработчика, который будет готов поддерживать гениальный, уникальный, сверхоптимизированный код?