Комментарии 27
Думаю не хватает подробностей, особенно хочется почитать про «обосновать руководству её необходимость».
А вот API для подключения расширений к Ноде на других языках несколько раз кардинально менялось. И если использовать модуль, написанный, скажем, на C++, который уже давно никем не сопровождается, то, чтобы его оживить, понадобится квалификация, скажем так, сильно отличающаяся от квалификации javascript-программиста.
Проект состоит из нескольких модулей, практически все из которых уже были практически готовы к такому переходу, кроме одного центрального, объёмом более 10к строк кода. В результате суммарно на переработку всего проекта ушло около полутора недель и ещё примерно неделя на обкатку и тестирование перед заливкой на продакшн
Пытался нагуглить какие-нибудь бенчмарки для сравнения новых нод со старыми, ничего толкового не нашёл.
А бенчмарки v8 не искали?
Искал. Но информации, достаточной для принятия решения не нашёл. Впрочем, это критерий слишком субъективный. Окончательное решение о переходе было скорее интуитивным, чем основывалось на реальных фактах. Плюс желание иметь нормальные возможности отладки, которые появились в ноде только с версии 0.12
Прежде чем начать, напомню основной принцип ИТ бизнеса: РАБОТАЕТ, НЕ ТРОГАЙ!
Проблема первая:
Один из компонентов при пиковых входящих нагрузках и расходе памяти под 5ГБ вдруг начинал адски тормозить.
Проблема вторая:
Другой из наших компонентов ел ощутимо много памяти.
А где оно работало?
Из за жадности бизнеса, потеряли много человеко часов на костыли, вместо того чтобы использовать новую версию где все баги исправлены.
Есть еще один принцип, СКУПОЙ ПЛАТИТ ДВАЖДЫ!..
Так он для читателей предупредил, дабы не сподвигнуть кого на неприятности своим примером. А ему то надо было. Иначе бы и статьи не получилось. Довольно куцей, кстати.
Может быть, сам инженер не видел для себя реальных преимуществ в переводе и оттягивал этот момент, пока уже не прижало.
Конечно, на хабре считается кощунственной идея о том, что программисты не начинают изучать и использовать в продакшене бета-версии новых технологий.
Но зрелость инженера, на мой взгляд, состоит именно в том, что он отдает себе отчет о том что нужно менять, а из чего нужно прям вырасти.
Да, Вы совершенно правы. Делать что-то только ради эстетики и развития кругозора можно тогда, когда для этого есть время. А если приходится выбирать между первоочередными задачами и желательными "хотелками", "хотелки" как правило откладываются в долгий ящик. Для сдвига бизнес-планов нужны веские основания. Плюс любая существенная переработка как правило предполагает баги и большие риски, что для работающего процесса может быть критично
А не думали перейти на go или java? у меня нет деталей задачи, как-то странно на парсинге логов потреблять 5гб оперативы
Задача сложнее, чем просто парсинг логов. Например, подшивка к логу юзера, обработку различных хуков и построение реалтаймовых агрегаций. И нода вполне с задачей справляется. Но вы совершенно правы, что расход в 5ГБ оперативы — это не нормально. Обычный рабочий расход памяти у данного компонента — менее одного гига. Перерасход происходит только в определённых исключительных ситуациях. И дело здесь не в языке, а в архитектурной недоработке. Мы знаем об этой недоработке, но более простым решением оказалось установить параметр --max-old-space-size в более высокое значение.
Да, тоже хотел сказать, что «работает — не трогай» — устаревший принцип. На практике, у каждого приложения 100500 зависимостей, если не обновлять платформу и зависимости, то очень быстро, за год-два, окажешься в вакууме на:
1) неподдерживаемой платформе/версии языка
2) без обновлений безопасности
3) без исправлений ошибок
4) без возможности воспользоваться современными инструментами и библиотеками
Да, эти постоянные обновления напрягают, и нередко что-нибудь ломают. Но если их не делать, то быстро оказываешься в безвыходном положении.
Отчасти Вы правы, отчасти нет. Несомненно хорошо бы стараться поддерживать приложение в актуальном состоянии. Но если приложение работает и справляется с возложенными на него обязанностями, зачем его трогать? Можно бесконечно рефакторить старый код. Вопрос: кто будет разрабатывать новый функционал? Иногда проще дать приложению выработать себя по максимуму и потом переписать с нуля.
Опять же, всё зависит от Ваших конкретных текущих задач и ресурсов. Универсальной формулы нет.
С чем столкнулись?
Естественно, не недостаток функционала. Новые фичи es6 даже не рассматривались как аргумент.

что начиная с версии 9.0.0, с производительностью стало еще лучше, чем 8 версии, в частности с памятью, которая в 8 ветке все еще имеет утечки, гораздо меньше, чем предыдущие версии
примерно с 9.3, утечек памяти уже не наблюдалось
… у нас просто была похожая задача, как и автора, и свое время тестили все новые версии ноды
Спасибо за информацию, взял на заметку. Брал ноду 8 только потому, что она LTS. Скорее всего 10-ка тоже вот-вот перейдёт в LTS статус, не вижу причин не перейти на неё.
По поводу утечек памяти скажу, что при наших объёмах (террабайты в сутки) утечки обязательно проявили бы себя. Значит либо в 8-й ноде утечки пофиксили, либо вы делаете что-то очень специфическое
Прежде чем начать, напомню основной принцип ИТ бизнеса: РАБОТАЕТ, НЕ ТРОГАЙ!
Не далее, чем полгода назад, меня попросили добавить одну небольшую функцию на сайт. Сразу скажу, сайт был не на NodeJS, вовсе даже на Python/Django. Так вот, для начала, этот сайт не удалось поднять ни на чистой машине, ни на клоне сервера, на котором он крутился. Любые попытки что-то как-то запустить упирались в то, что те библиотеки, которые там использовались, уже успели поменять API, а у многих вообще сменилась старшая версия. Например, у библиотеки, работающей с GIS PostgreSQL. Поставить старую было можно, но она хотела соответствующую старую версию PostgreSQL. А там, пожалуй, пришлось бы куда-то ставить соответствующую версию ОС. Кстати, пытались, но не помогло. Не помню уже почему. Для понимая масштабов, скажу, что Python там был где-то 2.6, а Django — 1.3 или 1.4. Убил довольно много времени, но так ничего и не смог сделать, потому что заказчик как раз придерживался вот такой точки зрения. Функция была небольшой и, по идее, несложной в реализации. Только вот подъём версий до актуальных как раз требовал довольно больших трудозатрат, а у заказчика эти как-то не совмещалось, что для того, чтобы что-то добавить, надо сделать проект хоть сколько-то актуальным. Вроде бы, там и сидят на старой версии.
Это всё к чему. Кидаться и вот прям щас всё обновлять, вероятно, не стоит. А вот что стоит делать — регулярно папать версии библиотек и прочего по мере их обновления. Тогда на каждой итерации трудозатраты буду близки к запуску
sudo <your-package-manager> update
и pip install --upgrade -r requirements.txt
на тестовом сервере и, если всё в порядке, запуску их же на боевом + перезапуск всего, что обновилось. Ну или всей системы. Причём, второе будет не к спеху — работает же, поэтому, если вдруг на тестовом всё перекосило, будет время плавно и ненавязчиво починить. Что, обычно, тоже много времени не занимает. А в итоге — никто полярный и пушистый внезапно не подкрадётся, потому что всё будет в актуальном состоянии и не придётся тратить месяц на одну мелкую доработку.Нашел на просторах интернета
К вопросу производительности старых и новых версий ноды