Как стать автором
Поиск
Написать публикацию
Обновить

Комментарии 27

Мрачноватое начало, всю статью держали в напряжении, я уже начал переживать что в конце кого-то накажут.

Думаю не хватает подробностей, особенно хочется почитать про «обосновать руководству её необходимость».

Ну это же не художественный роман) Цель статьи — дать какую-то обратную связь тем людям, которые ещё стоят перед выбором и сомневаются

Интересно сколько человеко-часов ушло и на какой объем кода.
НЛО прилетело и опубликовало эту надпись здесь
Ну вопервых автор указал на libmysqlclient и необходимость изменения всей архитектуры, что уже интересно. Во вторых что-то вроде nodejs.org/dist/latest-v8.x/docs/api/all.html#deprecations_deprecated_apis
Обновления самой Ноды изредка ломают обратную совместимость (в основном, отрубанием устаревших функций, для которых значительное время существует альтернатива), но это обычно легко отслеживается и правится, когда речь идет только о js-коде.

А вот API для подключения расширений к Ноде на других языках несколько раз кардинально менялось. И если использовать модуль, написанный, скажем, на C++, который уже давно никем не сопровождается, то, чтобы его оживить, понадобится квалификация, скажем так, сильно отличающаяся от квалификации javascript-программиста.

Проект состоит из нескольких модулей, практически все из которых уже были практически готовы к такому переходу, кроме одного центрального, объёмом более 10к строк кода. В результате суммарно на переработку всего проекта ушло около полутора недель и ещё примерно неделя на обкатку и тестирование перед заливкой на продакшн

Пытался нагуглить какие-нибудь бенчмарки для сравнения новых нод со старыми, ничего толкового не нашёл.

А бенчмарки v8 не искали?

Искал. Но информации, достаточной для принятия решения не нашёл. Впрочем, это критерий слишком субъективный. Окончательное решение о переходе было скорее интуитивным, чем основывалось на реальных фактах. Плюс желание иметь нормальные возможности отладки, которые появились в ноде только с версии 0.12

Прежде чем начать, напомню основной принцип ИТ бизнеса: РАБОТАЕТ, НЕ ТРОГАЙ!

Проблема первая:
Один из компонентов при пиковых входящих нагрузках и расходе памяти под 5ГБ вдруг начинал адски тормозить.

Проблема вторая:
Другой из наших компонентов ел ощутимо много памяти.

А где оно работало?
Из за жадности бизнеса, потеряли много человеко часов на костыли, вместо того чтобы использовать новую версию где все баги исправлены.
Есть еще один принцип, СКУПОЙ ПЛАТИТ ДВАЖДЫ!..

Так он для читателей предупредил, дабы не сподвигнуть кого на неприятности своим примером. А ему то надо было. Иначе бы и статьи не получилось. Довольно куцей, кстати.

Вы уверены, что это именно злой директор зажимал перевод приложения на обновленные версии ноды?

Может быть, сам инженер не видел для себя реальных преимуществ в переводе и оттягивал этот момент, пока уже не прижало.

Конечно, на хабре считается кощунственной идея о том, что программисты не начинают изучать и использовать в продакшене бета-версии новых технологий.

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

Да, Вы совершенно правы. Делать что-то только ради эстетики и развития кругозора можно тогда, когда для этого есть время. А если приходится выбирать между первоочередными задачами и желательными "хотелками", "хотелки" как правило откладываются в долгий ящик. Для сдвига бизнес-планов нужны веские основания. Плюс любая существенная переработка как правило предполагает баги и большие риски, что для работающего процесса может быть критично

НЛО прилетело и опубликовало эту надпись здесь

А не думали перейти на go или java? у меня нет деталей задачи, как-то странно на парсинге логов потреблять 5гб оперативы

Задача сложнее, чем просто парсинг логов. Например, подшивка к логу юзера, обработку различных хуков и построение реалтаймовых агрегаций. И нода вполне с задачей справляется. Но вы совершенно правы, что расход в 5ГБ оперативы — это не нормально. Обычный рабочий расход памяти у данного компонента — менее одного гига. Перерасход происходит только в определённых исключительных ситуациях. И дело здесь не в языке, а в архитектурной недоработке. Мы знаем об этой недоработке, но более простым решением оказалось установить параметр --max-old-space-size в более высокое значение.

Откройте для себя graylog или elk
Напомню основной принцип ИТ бизнеса: ОБНОВЛЯЙ ПОСТОЯННО. Если периодически обновлять на стабильную версию с задержкой в пару месяцев (чтобы первые баги успели пофиксить), то проблем придется решать значительно меньше. И уж точно не придется сталкиваться с тем, что разработчики уже давно пофиксили.

Да, тоже хотел сказать, что «работает — не трогай» — устаревший принцип. На практике, у каждого приложения 100500 зависимостей, если не обновлять платформу и зависимости, то очень быстро, за год-два, окажешься в вакууме на:
1) неподдерживаемой платформе/версии языка
2) без обновлений безопасности
3) без исправлений ошибок
4) без возможности воспользоваться современными инструментами и библиотеками


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

Отчасти Вы правы, отчасти нет. Несомненно хорошо бы стараться поддерживать приложение в актуальном состоянии. Но если приложение работает и справляется с возложенными на него обязанностями, зачем его трогать? Можно бесконечно рефакторить старый код. Вопрос: кто будет разрабатывать новый функционал? Иногда проще дать приложению выработать себя по максимуму и потом переписать с нуля.
Опять же, всё зависит от Ваших конкретных текущих задач и ресурсов. Универсальной формулы нет.

Один знакомый примерно так описывает разницу систем здравоохранения в СССР и в США: в США было лучше с лечением, сильно лучше, но в СССР лучше была поставлена работа по сохранению и поддержанию здоровья. Так вот, поддержание версий платформы, интерпретатора, если используется, библиотек и прочего в актуальном состоянии — это то самое «сохранение здоровья». Пока не сломалось, чинить не надо, но регулярная поддержка сильно снижает риск поломки ценой небольших затрат времени на стыковку «разбежавшихся» API. Я ниже описал, к чему приводит нежелание проводить профилактику. Вам повезло — конечное решение принимали Вы, а вот тому моему клиенту пришлось куковать без нового функционала, потому что оплачивать «лечение» его начальство отказалось.
С чем столкнулись?

Естественно, не недостаток функционала. Новые фичи es6 даже не рассматривались как аргумент.


image
еще хотел добавить про ноду…
что начиная с версии 9.0.0, с производительностью стало еще лучше, чем 8 версии, в частности с памятью, которая в 8 ветке все еще имеет утечки, гораздо меньше, чем предыдущие версии

примерно с 9.3, утечек памяти уже не наблюдалось

… у нас просто была похожая задача, как и автора, и свое время тестили все новые версии ноды

Спасибо за информацию, взял на заметку. Брал ноду 8 только потому, что она LTS. Скорее всего 10-ка тоже вот-вот перейдёт в LTS статус, не вижу причин не перейти на неё.


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

да, у нас специфические задачи
на текущий момент используем 10ю версию, показатели даже лучше чем у 9 версии
Прежде чем начать, напомню основной принцип ИТ бизнеса: РАБОТАЕТ, НЕ ТРОГАЙ!

Не далее, чем полгода назад, меня попросили добавить одну небольшую функцию на сайт. Сразу скажу, сайт был не на 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
на тестовом сервере и, если всё в порядке, запуску их же на боевом + перезапуск всего, что обновилось. Ну или всей системы. Причём, второе будет не к спеху — работает же, поэтому, если вдруг на тестовом всё перекосило, будет время плавно и ненавязчиво починить. Что, обычно, тоже много времени не занимает. А в итоге — никто полярный и пушистый внезапно не подкрадётся, потому что всё будет в актуальном состоянии и не придётся тратить месяц на одну мелкую доработку.
В обновления Node периодически включены обновления V8 с оптимизацией перфоманса, так что обновление Node в большинстве случаев дает положительный эффект.

Нашел на просторах интернета
Зарегистрируйтесь на Хабре, чтобы оставить комментарий

Публикации