Каков масштаб проекта? У нас в проекте использование профайлера весьма затруднено из-за чудовищной вложенности вызовов, которая в свою очередь является следствием огромной кодобазы и массы библиотек, пробовали профилировать — погрязли в цепочках вызовов, плюнули, оставили как есть. Очевидно, что нужен рефакторинг, но непонятно в какую сторону двигаться.
В общем, присоединюсь к просьбе поделиться опытом, возможно даже в виде статьи, а не комментария :)
Я не могу понять чем так плохо раз в сутки ребутнуть инстанс ноды?
Зависит от нагрузки :) Ребут инстанса означает, что некоторые клиенты могут отвалиться от сервиса или не смогут достучаться до него. Если ночью инстанс пустует — почему бы и нет.
именно на продакшине надо запустить npm test и убедиться что все работает
Вы не думали о внедрении continuous integration с прогоном всех тестов на тестовых средах, идентичных боевым?
Да. Она там правда не совсем встроенная и тоже использует node-cluster, правда с весьма солидным обвесом. Поэтому и падало, собственно. Был даже вот такой замечательный баг: github.com/nodejs/node-v0.x-archive/issues/9261
И я кажется наврал насчет версии, вроде в io v3 фикс уже приземлился :)
Несколько сумбурно написано и структурированности не хватает. По пунктам:
Теперь перед этими 4-ма инстанами нужно установить балансировщик, который будет распределять нагрузку
Тут, есть множество вариантов, например: Запустить еще один инстанс ноды и задействовать модуль cluster
Cluster-модуль содержит балансировку по воркерам внутри себя, ничего дополнительно ставить не нужно. А вот для статики — действительно, неплохо иметь nginx сверху. Но это опять же ничуть не исключает наличия кластер-модуля в апстриме.
Периодичность перезагрузки (в зависимости от разных причин) от 1 раза в час до 1 раза в сутки.
Я могу понять когда сервис жрет память и не отдает (от чего кстати хорошо помогают лимиты по использованию памяти в pm2), но от чего сервис может становиться более медленным с течением времени — непонятно. Так или иначе, выше уже упомянули про graceful reload. И да, перезагружать весь инстанс довольно странно, если есть кластер-модуль и можно, грубо говоря, послать SIGTERM медленному воркеру.
написано множество cli утилит, которые следят за процессом ноды и в случае необходимости его перегружают
Не могу сказать за остальные три, но могу сказать за pm2 — падает как миленький весь God Daemon :) Особенно на node/io от 0.11 до 4.1.2, из-за бага, имевшего место быть в тех версиях в модуле кластера. Так что за pm2 тоже желательно следить, через upstart-скрипт, например. А можно вообще впилить голый кластер-модуль и мониторить/перезагружать его опять же через upstart.
По пункту 10 — чот вообще вcё в кучу смешалось. Да, мониторинг нужен. Да, юнит-тестирование нужно. Но из пункта сложилось впечатление, что вы предлагаете использовать mocha/jasmine на продакшене для проверки окружения о.0 Это довольно странный способ использования этих фреймворков.
Для меня несколько странно звучит, когда противопоставляют именно ООП и ФП, а не императивщину и функциональщину.
Что касается простоты — поправьте, если я не прав, но мне как человеку довольно поверхностно знакомому с функциональными языками кажется, что современные языки типа эрланга, хаскеля добавляют какие-то невероятные объемы сложности туда, где они совершенно не требуются.
Хотя не могу поспорить с тем, что есть некоторые вполне конкретные применения (типа каких-то супер-многопоточных сервисов, способных держать хреналион одновременных коннектов), где тот же эрланг может подойти гораздо лучше других решений. Но это опять же — относится к конкретной экосистеме, а не к ФП в целом.
Статья вызывает смешанные чувства. С одной стороны, все упомянутые принципы (преподносимые как основополагающие для ФП) известны и полезны, но нет никаких препятствий для того, чтобы придерживаться этих принципов в языках императивных. С другой стороны, складывается впечатление, аналогичное тому, когда некто упорно и назойливо пытается продвигать свои взгляды как единственно верные, как панацею и серебряную пулю. Но при этом вероятные проблемы, с которыми столкнется программист на чисто функциональном языке в попытке описать идеальными методами наш неидеальный мир — в очередной раз элегантно замалчиваются.
А вы дальше первого абзаца, очевидно, не читали? «У браузеров (и в node.js) основная петля вшита.» Спецификация это безусловно круто, только в спецификациях говорится о том, как это должно работать, но ничего не говорится о том, как это должно быть реализовано.
И да, покажите хотя бы одну реализацию, где нет event loop.
Неправильно понимаете.
К тому же, если рассматривать любой язык в отрыве от реализации, в любом языке из коробки нет ничего, кроме формальной грамматики.
Событийность из коробки? Возможность писать в разных стилях (императивный, функциональный, объектный, процедурный, да даже декларативный прости господи) без принуждения к какому-то конкретному? Отсутствие необходимости осваивать мегабайтные фреймворки, чтобы написать hello world?
Ну и да, хотя изоморфность довольно спорна сама по себе, перспектива писать на одном и том же языке в бэкенде и фронтенде достаточно интересна и привлекательна. Плюс сокращение объема кодобазы.
Еще раз — диспозиционные типологии несостоятельны. То есть нет и не может быть таксономии, определяющей единый и неизменный тип личности. Мне известно, что на данный момент рассматриваются ситуационные модели, которые учитывают не только какие-то эфемерные сборные признаки, но и предыдущий опыт человека, а также ситуацию, в которой производится наблюдение.
Эти выводы исходят из заведомо ложной предпосылки о доказанном существовании типов личности, и именно это вызывает отторжение. В среде психологов уже давно известна несостоятельность диспозиционных типологий.
Простыми словами: в исследовании проводится классификация пользователей по заранее заданным группам, вместо кластеризации и последующего выявления особенностей найденных групп. Где обоснование того, что групп не больше и не меньше? Откуда взялось предположение, что пользователь не может принадлежать к нескольким группам одновременно? Каковы критерии истинности данного разбиения, т.е. как мы поймем что классификация проведена корректно? И таких вопросов очень, очень много.
В общем, присоединюсь к просьбе поделиться опытом, возможно даже в виде статьи, а не комментария :)
Вы не думали о внедрении continuous integration с прогоном всех тестов на тестовых средах, идентичных боевым?
И я кажется наврал насчет версии, вроде в io v3 фикс уже приземлился :)
Cluster-модуль содержит балансировку по воркерам внутри себя, ничего дополнительно ставить не нужно. А вот для статики — действительно, неплохо иметь nginx сверху. Но это опять же ничуть не исключает наличия кластер-модуля в апстриме.
Я могу понять когда сервис жрет память и не отдает (от чего кстати хорошо помогают лимиты по использованию памяти в pm2), но от чего сервис может становиться более медленным с течением времени — непонятно. Так или иначе, выше уже упомянули про graceful reload. И да, перезагружать весь инстанс довольно странно, если есть кластер-модуль и можно, грубо говоря, послать SIGTERM медленному воркеру.
Не могу сказать за остальные три, но могу сказать за pm2 — падает как миленький весь God Daemon :) Особенно на node/io от 0.11 до 4.1.2, из-за бага, имевшего место быть в тех версиях в модуле кластера. Так что за pm2 тоже желательно следить, через upstart-скрипт, например. А можно вообще впилить голый кластер-модуль и мониторить/перезагружать его опять же через upstart.
По пункту 10 — чот вообще вcё в кучу смешалось. Да, мониторинг нужен. Да, юнит-тестирование нужно. Но из пункта сложилось впечатление, что вы предлагаете использовать mocha/jasmine на продакшене для проверки окружения о.0 Это довольно странный способ использования этих фреймворков.
Скорее всего людям не хватило стандартной функциональности приложения.
Что касается простоты — поправьте, если я не прав, но мне как человеку довольно поверхностно знакомому с функциональными языками кажется, что современные языки типа эрланга, хаскеля добавляют какие-то невероятные объемы сложности туда, где они совершенно не требуются.
Хотя не могу поспорить с тем, что есть некоторые вполне конкретные применения (типа каких-то супер-многопоточных сервисов, способных держать хреналион одновременных коннектов), где тот же эрланг может подойти гораздо лучше других решений. Но это опять же — относится к конкретной экосистеме, а не к ФП в целом.
И да, покажите хотя бы одну реализацию, где нет event loop.
К тому же, если рассматривать любой язык в отрыве от реализации, в любом языке из коробки нет ничего, кроме формальной грамматики.
Ну и да, хотя изоморфность довольно спорна сама по себе, перспектива писать на одном и том же языке в бэкенде и фронтенде достаточно интересна и привлекательна. Плюс сокращение объема кодобазы.
Простыми словами: в исследовании проводится классификация пользователей по заранее заданным группам, вместо кластеризации и последующего выявления особенностей найденных групп. Где обоснование того, что групп не больше и не меньше? Откуда взялось предположение, что пользователь не может принадлежать к нескольким группам одновременно? Каковы критерии истинности данного разбиения, т.е. как мы поймем что классификация проведена корректно? И таких вопросов очень, очень много.