В чем секрет скорости NodeJS?

Автор оригинала: Евгений Обрезков
  • Перевод
Предлагаем вам перевод статьи Евгения Обрезкова, в которой он кратко и по делу рассказывает о причинах высокой скорости NodeJS: потоки, event loop, оптимизирующий компилятор и, конечно же, сравнение с PHP. Куда уж без него.



В очередной статьей о NodeJS хочу поговорить об ещё одном преимуществе программной платформы: о скорости выполнения кода.

Что мы имеем в виду под скоростью выполнения


Вычислить последовательность Фибоначи или отправить запрос к базе данных?

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

Как только вы поймёте, что происходит в сервере NodeJS во время выполнения запроса, вам станет ясно, почему это происходит так быстро.

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

От чего страдает PHP


Вот список того, что уменьшает скорость выполнения кода в PHP:

  • PHP имеет синхронную модель выполнения. Это означает, что когда вы обрабатываете запрос или пишете в базу данных, другие операции блокируются. Поэтому приходится ждать окончания операции, прежде чем начать делать что-то другое.
  • Каждый запрос к веб-сервису создает отдельный процесс PHP интерпретатора, который выполняет ваш код. Тысячи подключений означают тысячи выполняющихся процессов, которые потребляют память. Вы можете наблюдать, как память используется всё больше и больше вместе с новыми подключениями.
  • PHP не имеет JIT компилятора. Это важно, если у вас есть код, который используется очень часто, и вы хотите быть уверенными в том, что он близок к машинному коду, насколько это возможно.

Это самые критичные минусы PHP. Но, по моему мнению, их намного больше.

Теперь мы посмотрим, как NodeJS справляется с подобными задачами.

Магия NodeJS


NodeJS однопоточна и асинхронна. Любая операция ввода-вывода не блокирует работу. Это значит, что ты можешь читать файлы, отправлять электронные письма, запрашивать базу данных и совершать другие действия… одновременно.

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

Виртуальная машина в NodeJS (V8), которая выполняет JavaScript, имеет JIT компиляцию. Когда виртуальная машина получает исходный код, она может скомпилировать его прямо во время работы. Это значит, что операции, которые вызываются часто, могут быть скомпилированы в машинный код. И это значительно улучшит скорость выполнения.

По сути, здесь были изложены преимущества асинхронной модели. Позвольте мне объяснить, как это работает в NodeJS.

Понимайте вашу асинхронность


Вашему вниманию предлагаю пример концепции асинхронной обработки (спасибо Кириллу Яковенко).

Представьте, что у вас есть 1000 шаров на вершине горы. И ваша задача – толкнуть все шары, чтобы они оказались у её основания. Вы не можете толкнуть одновременно тысячу шаров, только каждый по отдельности. Но это не значит, что вы должны ждать, когда шар достигнет основания, чтобы толкнуть следующий.

Синхронное выполнение означает для вас потерю времени. Вы ждете, когда шар окажется у основания.

Асинхронное выполнение похоже на то, что у вас появляется 1000 дополнительных рук. И вы можете запустить все шары одновременно. После чего ждете только сообщения о том, что все они внизу, и собираете результаты.

Как асинхронное выполнение помогает веб-сервису работать?

Представим, что каждый шар – это запрос в базу данных. У вас большой проект, где много запросов, аггрегаций, и так далее. Когда вы обрабатываете все данные синхронным способом, это блокирует выполнение кода. Асинхронным способом вы выполняете все запросы одновременно, а затем только собираете данные.

В реальной жизни, когда у вас много соединений, это значительно ускоряет работу.

Как асинхронный способ реализован в NodeJS?

Event Loop


Event loop – это конструкция, которая ответственна за обработку событий в какой-то программе. Event loop почти всегда работает асинхронно относительно источника сообщений. Когда вы вызываете операцию ввода-вывода, NodeJS сохраняет коллбек, связанный с этой операцией, и продолжает обработку других событий. Коллбэк будет вызван, когда все необходимые данные будут получены.

Наиболее развернутое определение event loop:

Event loop, message dispatcher, message loop, message pump или run loop – это программная конструкция, которая ожидает и обрабатывает события или сообщения в программе. Конструкция работает путем создания запросов к внутренней или внешней службе доставки сообщений (которая обычно блокирует запрос до тех пор, пока сообщение не получено), после чего она вызывает обработчик соответствующего события («обрабатывает событие»). Event loop может быть использована в связке с reactor, если источник событий имеет такой же интерфейс как и файлы, к которому можно сделать запрос вида select или poll (poll в смысле Unix system call). Event loop почти всегда работает асинхронно по отношению к источнику сообщений.

Давайте посмотрим на простую иллюстрацию, которая объясняет, как event loop работает в NodeJS.



Event Loop в NodeJS


Когда веб-сервис получает запрос, тот отправляется в event loop. Event loop регистрирует операцию в пуле потоков с нужным коллбеком. Коллбек будет вызван, когда обработка запроса завершится. Ваш коллбек может также делать другие «тяжелые» операции, такие как запросы в базу данных. Но делает это таким же способом – регистрирует операцию в пуле потоков с нужным коллбеком.

Как насчет выполнения кода и его скорости? Мы собираемся поговорить о виртуальной машине и о том, как она выполняет JavaScript код. То есть о V8.

Как V8 оптимизирует ваш код?


В Wingolog описано, как работает виртуальная машина V8. Я упростил изложенный там материал и предлагаю выжимку.

Ниже будут обозначены базовые принципы работы виртуальной машины V8 и способы того, как она оптимизирует код JavaScript. Это будет техническая информация, поэтому можете пропустить эту часть, если не знаете, как работают компиляторы. А если вы хотите знать больше о V8, то советую обратиться к специализированному источнику.

V8 имеет три типа компилятора, но обсудим только два: Full и Crankshaft (третий компилятор называется Turbofun).

Full-компилятор работает быстро и производит «типовой код». У функции Javascript он берет AST (Abstract Syntax Tree) и переводит его в типовой нативный код. На этом этапе применяется только одна оптимизация – инлайн кэширование.

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

После того, как V8 определила, какие функции используются часто, и получила отчет об использовании типов, она старается запустить модифицированный AST через оптимизирующий компилятор – Crankshaft.

В отличие от Full-компилятора, Crunshaft работает не так быстро, но пытается производить оптимизированный код. Cranshaft состоит из двух компонентов: Hydrogen и Lithium.

Hydrogen-компилятор создает CFG (Control Flow Graph) из AST (на основании отчета об использовании типов). Этот граф представлен в форме SSA (Static Single Assignment). На основании простой структуры HIR (High-Level Intermediate Representation) и формы SSA, компилятор может применять много оптимизаций, таких как constant folding, method inlining, и так далее…

Lithium-компиллятор переводит оптимизированный HIR в LIR (Low-Level Intermediate Representation). LIR концептуально похож на машинный код, но в большинстве случае не зависит от платформы. В противоположность HIR, форма LIR — ближе к three-address коду.

Только после этого, оптимизированный код может заменить старый неоптимизированный и продолжить выполнять ваше приложение намного быстрее.

Полезные ссылки


Voximplant
198,08
Облачная платформа голосовой и видеотелефонии
Поделиться публикацией

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

    +27
    PHP имеет синхронную модель выполнения.


    NodeJS тоже. просто есть из коробки неблокируемое API. А так все вполне синхронно. В PHP проблема что асинхронщины из коробки нет, есть возможность делать корутины. Ну и в целом ситуация по PHP примерно такая: https://github.com/elazar/asynchronous-php
    Каждый запрос к веб-сервису создает отдельный процесс PHP интерпретатора


    Опять же, это не ограничение платформы, это дефакто стандарт. Но никто вам не мешает взять reactphp и вперед. Другой вопрос что рациональность этого под вопросом так как "умирание" PHP его основной плюс.
    Вы можете наблюдать, как память используется всё больше и больше вместе с новыми подключениями.


    5 воркеров обрабатывающих один запрос на PHP памяти жрут всеравно чуть меньше чем nodejs. Ну а так как в штуках типа php-fpm 5 воркеров это максимум (настройки по умолчанию если брать) то как бы все хорошо.

    Мне тут на днях понадобилась простенькая тула, и так как я не хотел ее писать, взял готовое под nodejs. Но вот проблема, операция над одним файлом занимала 0.01 секунду (и на php было бы так же), а холодный старт порядка секунды. И автор тулзы не дал возможности делать пакетную обработку.

    Так что все относительно.
      0
      Ради обсуждения на Хабре и публикуется. ReactPHP пробовали? Как оно в продакшн?
        +5
        Нормально в продакшене. Есть специализированный чатик, уже скоро год как стабильно работает, утечек памяти нет, перезапускаю только при обновлении софта.
          +4
          У нас на reactphp крутиться вся работа с очередями, вэб сокетами, таймерами и т.д.
          Работает отлично.
            +1
            Довольны, используем уже больше года на нескольких проектах
            +1
            Асинхронность в php — это не стандарт разработки, в отличие от node.js, где неблокирующее API — стандарт, который в первую очередь описывается во всех мануалах.

            node.js хорош именно тем, что «направляет» писать довольно быстрые приложения.
              0
              Асинхронность в php — это не стандарт разработки


              Скорее не мэйнстрим. А техническая возможность имеется уже очень давно.
                0
                Это и имелось в виду. Эта возможность не ставится на первый план.
            –10
            Не совсем понимаю, почему nodeJS сравнивают с php. Для меня nodeJS больше к фронтенду отношения имеет, нежели к бекенду, как на картинке:
            Картинка
            image

            Есть у кого нибудь опыт написания полноценного бекенда на ноде? Я не про чатики говорю :)
              +7
              Чатики сложнее чем бложики писать.
                0
                А я про бложики и не говорю :)
                Многие хвалят ноду в контексте «убийцы PHP», но я ни разу не видел пример реализации высоконагруженного бекенда с какой то бизнес-логикой.
                Фронтенд да, делают и вроде все хорошо. А про бекенд только разговоры и сомнительные сравнения.
                0
                Cowboy+bullet с вами не согласятся.
                  0
                  пхп не убьешь, учитывая кол-во сайтов на Drupal, Joomla и прочих CMS
                    +1
                    Вот первые два точно стоит убить. вместе с битриксом, а тот же Вордпресс чем дальше тем светлее, судя по слова моих знакомых разработчиков.
                    Извините, по моей статистике работы на двух хостингах в вп проблема в кривых/украденных плагинах/темах, а в первых Ваших двух указанных — проблема в ядре. Если брать мою субьективную статистику проломанных сайтов на всех моих хостингах, Вп ломают сильно меньше, чем жумлу/друпал, даже при том, что половина вордпрессиков на хостингах ещё тех версий которые не умеют автообновления
                      0
                      А какая альтернатива есть для WP?
                      Typo не предлагать.
                0
                На скриншоте изображена какая-то дичь. Судя по нему, нода выступает как прокси для доступа к бэкэнду (там должен быть Nginx в таком случае).

                Я писал на Node.js бота, выставлял к нему REST API через Express и это всё отлично работает по сей день. REST можно было пользоваться как с PHP бэкэнда, так и прямо с клиента. У ноды есть достаточно шаблонизаторов, чтобы обеспечивать и полноценные сайты с интерфейсом.
                  +1
                  Почему же дичь, картинка отсюда: https://habrahabr.ru/post/197358/
                    0
                    Так вот же и обсуждение оттуда же: https://habrahabr.ru/post/197358/#comment_6845970

                    Конечно, я не писал на Node.js большие проекты (какие писал на PHP), но считаю, что написать на Node.js большой проект не составит большего труда (при должном знании языка, конечно), чем сделать это на PHP. Использовать Node.js в качестве прокси-шаблонизатора — кощунство. В конце-концов, мы живём в 2016 году, когда ReactJS и Angular как раз и диктуют требования писать backend как REST API.
                      0
                      Мне кажется, тут все зависит от того, что считать большим проектом. И дело тут не в самом Node.js, а в инфраструктуре.

                      Если речь идет о большом монолитном проекте с массой бизнес-логики, то тут Node.js просто не предоставляет достаточно подходящего фреймворка, позволяющего писать ООП-код в SOLID/DDD-стиле (про сам язык Javascript ничего не говорю — тут Typescript все вопросы решает). Самое принципиальное — отсутствие Data Mapper ORM; все, что я видел (и даже содержит в названии или описании слова data mapper), по сути вариации на тему Active Record.

                      Если же применять микросервисную архитектуру, бизнес-логики немного и все сводится к CRUD, то без разницы — и для PHP, и для Node.js есть хорошие инструменты, при этом у Node.js есть некоторое преимущество в возможном code reuse на клиенте и сервере. Это хорошо, но не всегда подходит.
                        +1
                        возможном code reuse на клиенте и сервере

                        Из опыта: Вероятность использования кода стремится к нулю.
                        Скорее пользы больше от того, что хорошо знаешь JS и используешь эти знания и в Back-End и во Front-End
                          0
                          Вероятность использования кода стремится к нулю.

                          Зависит от задачи и опыта разработчика. Если из задач клиента и сервера "реюз" маловероятен — то значит его и не будет. Но если есть возможность этот код реюзать — то тогда 90% что все будет хорошо.


                          Самый пожалуй банальный пример — SPA и их пререндеринг на сервере. Мы пишем приложение на каком-нибудь react/ember/angular2, и, если мы изначально заложили адекватную архитектуру (о чем многие забывают) мы можем довольно быстро и безболезненно добавить пререндеринг для оптимизации "первой" загрузки странички. А бэкэнд — для простеньких приложений можно вообще firebase-ами обойтись, а так это обычно простенький stateless api.


                          То есть мы имеем ооочень простой бэкэнд (хотя зависит от задачи), ооочень удобный интерфейс и 95% нашего кода клиента реюзается на сервере для пререндеринга. Что собственно мы и обсуждаем.

                  0
                  Что такое полноценный бэкенд? :)
                  Мы используем ноду на бэке в некоторых местах и проблем пока особо не наблюдается
                    0
                    Есть у кого нибудь опыт написания полноценного бекенда на ноде?

                    Писал браузер игровых серверов Quake Live. Данные о серверах хранятся в виде словаря «адрес — состояние» (в состояние входит название сервера, режим игры, количество игроков и т.п.). Сам словарь представлен, как обычная переменная, т.к. памяти для 1000 серверов хватает. Все состояния успевают обновляться примерно за минуту. И все это на node.js.

                    На бэкенде выдает статические файлы и данные в формате json. Фронтенд — это html + браузерный js.
                      +2
                      Уже пятый год у моего клиента работает система информатизации производственных процессов на оконном производстве (евроокна). Задачи системы:
                      — демонстрация технологических карт изделий на участках конвейера;
                      — фиксирование операций с изделиями;
                      — предоставление в реальном времени данных о состоянии отдельных изделий и в целом состояния производства;
                      — аналитика выработки на участках и конкретными сотрудниками;
                      — учёт контроля качества;
                      — складской учёт готовых изделий и стеклопакетов;
                      — планирование графика отгрузки со склада;
                      — автоматическое уведомление клиентов о готовности заказа по SMS;

                      Все интерфейсы системы реализованы как реалтайм веб-приложения использующие Socket.io.

                      Система писалась на NodeJS версии 0.6, потом была переведена на 0.8 и сейчас уже на 0.12. С переходом проблем не было.
                      Максимальный аптайм NodeJS процесса системы который удалось наблюдать — более 200 дней. Утечек памяти за это время не зафиксировано.
                        0
                        Любопытства ради — сколько примерно человеко-часов заняла реализация?
                    +6
                    Как V8 оптимизирует ваш код?

                    А где подобный раздел о том, как это делает PHP? Очередная статья из категории «Я знаю много о node.js но понятия не имею ни чего о внутренностях PHP».
                      +1
                      Отличная презентация из первых рук как сейчас в PHP 7.0 и что будет в 7.1
                        +2
                        А где подобный раздел о том, как это делает PHP?


                        А PHP просто не оптимизирует код в рантайме. Ну то есть вообще. Все оптимизации происходят только на уровне парсинга исходников, в то время как в nodejs "горячий" код прогоняется оптимизирующим компилятором и в итоге мы можем получить весьма эффективный машинный код.
                        +6
                        PHP не имеет JIT компилятора.

                        Если нужен JIT — используйте HHVM. Впрочем, PHP 7.x и без JIT приблизилась по скорости к hhvm, при этом «jit capability» в движке 7 есть.
                          +20

                          Секрет скорости node.js в миллионах долларов, вбуханных гуглом в V8.

                          –5
                          У ноды один плюс в сравнении с похапе — это вебсокеты. Но при это оба отстают на бесконечность от го.
                            +3
                            Кхм-кхм Сокеты в PHP
                            • НЛО прилетело и опубликовало эту надпись здесь
                                +2
                                Ну привет. Как это другие? Я лично строил чатик на вебсокетах с php в роли сокет-сервера. Потом, правда, переписал всё на nodejs, он получше заточен под сокеты, но! Клиентскую часть никак не менял. Это точно те же самые сокеты как и на ноде.
                                  –5

                                  возможно я ошибаюсь — вы точно вебсокеты с беркли сокетами не путаете? Вебсокеты — это надстройка над вторым http.

                                    +5
                                    Почему же над вторым? Над HTTP 1.1 пожалуй все же.
                                  • НЛО прилетело и опубликовало эту надпись здесь
                                      +1
                                      Посыпаю голову пеплом. Года два назад игрался, забыл как оно было. Поверх этих сокетов писал реализацию именно web-сокетов, «с коробки» их действительно нет.
                              +2
                              —Пациент, что вы видите, глядя на программу, написанную на NodeJS?
                              —Женщину в спортивной одежде, очень быстро бегущую.
                                +8
                                И где вся эта невероятная скорость, когда делаешь npm install?
                                  0

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

                                    +2
                                    NPM во всём проигрывает композеру (ну разве что кроме того что модульность JS позволяет избежать конфликта версий пакетов). npm shrinkwrap отвратителен в сравнении с lock-файлами композера или bundler. NPM 3 медленнее NPM2. Все попытки заменить сам NPM на более быстрый загрузчик пока к сожалению не продакшен-реди. Наличие native extensions не позволяет в отчаянии взять и запаковать node_modules в реп.

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

                                    А то что самих пакетов много – это уже дело десятое.
                                      +1
                                      Ну и у composer нет native extensions. Финиш.
                                        0

                                        https://github.com/composer/composer/pull/2898


                                        Но это просто к тому что все можно сделать. Как минимум на хуках дергать pecl install. Я считаю npm более "законченным" продуктом.

                                  +23
                                  NodeJS однопоточна и асинхронна. Любая операция ввода-вывода не блокирует работу. Это значит, что ты можешь читать файлы, отправлять электронные письма, запрашивать базу данных и совершать другие действия… одновременно.

                                  Вот любят возводить преимущества асинхронности в абсолют и совсем не обращать внимание на нюансы!

                                  Асинхронность дает преимущество только для IO-bound операций. И при преобладающем количестве IO асинхронность будет рулить!

                                  При CPU-bound операциях (сложная логика обработки данных из базы) при однопоточной модели event-loop лишь увеличивают задержку ответа.

                                  пример: Два запроса с количеством CPU-bound операций N и K соответственно. Как ни крути, но выполнить меньше не получится. Время на выдачу первого ответа: time( N + K' ), второго: time( N' + K ), где N' и K' — это операции, которые будут выполнены благодаря переключению контекстов (асинхронно).

                                  Если нагрузить NodeJS множеством длительных CPU-bound операций он будет обрабатывать запросы дольше, чем тот же PHP, который использует «железные» потоки.

                                  Сравнивать PHP и NodeJS — это как сравнивать «теплое с мягким».
                                  PHP — «живет, чтобы умирать», и в отличии от NodeJS из коробки не имеет ни пула воркеров, ни JIT, ни кешей.

                                  У каждого из них свой путь чем-то лучше, чем-то хуже!
                                    +5
                                    +++ Андрей. Практически озвучили мои мысли
                                    +1
                                    А в node.js под linux чтение файла при нагруженном диске ставит колом весь поток (единственный?) node.js?
                                      +1
                                      нет, для чтения файлов и других I/O операций используется ThreadPool, ответа от которого ждет непосредственно сама нода. А пока она ждет, может заняться другими вещами
                                        0
                                        О, это мне и было интересно узнать.
                                      –7
                                      да говнонода асинхронная. но она однопоточная и динамически типизируемая — поэтому необходимо делать дополнительные проверки и следить что не текло.
                                      в отличии от пыхапе — который умирает осле исполнения запроса — меньше траха с соблюдением состояния приложения.

                                      приимуществ у nodejs перед php нет.
                                      вот Go — это круто — там и типизация и горутины с автомасштабирование по процессам и коллбеков нету и костыли не нужны типа async await — которые хоть как то уменьшают боль от неправильной архитектуры «асинхронности» nodejs.
                                        +2
                                        да говнонода асинхронная. но она однопоточная и динамически типизируемая


                                        а PHP не динамически типизируем? Если вам не хватает информации о типах — https://flowtype.org/ и все хорошо. Для статического анализа все что нужно есть (и получше чем в PHP) а в рантайме это обычно уже и не нужно. Ну и не стоит забывать что система типов в JS чуууть лучше чем в PHP.
                                        приимуществ у nodejs перед php нет.


                                        ошибаетесь) Это я вам как похапэшник заявляю.
                                        вот Go — это круто — там и типизация и горутины с автомасштабирование по процессам


                                        по процессам или потокам? Мне как-то казалось что по потокам. Ибо если по процессам: https://nodejs.org/api/cluster.html — ровно то же самое по сути. Просто не так "прозрачно" для разработчика.
                                          0
                                          А, кстати, схему «мастер работает рутом, а детки дропают привелегии» в этом кластере до сих пор так и не сделали, или я плохо смотрю?

                                          Во времена ноды то ли 0.2, то ли 0.3 был доступен posix api, на нем я легко и быстро повторил классическую юникс-схему, по которой работает тот же nginx, и спокойно себе слушал 80-й порт. Потом posix api зачем-то выбросили, кажется, это случайно совпало с чемоданом денег из Microsoft, после которого сразу заговорили о кроссплатформенности, которая свелась к тому, что posix-вызовы выкинули, а замену — ну… как-нибудь потом. С тех пор, так сказать, осадочек остался.
                                            0
                                            я кто му что нет разницы php нода жс или еще какйото скриптовой язык
                                            php выигрывает — более простой разработкой — после запроса умирает и очищается состояние — не нужно следить
                                            в остальных динамических языках сложнее — а профита практически нет.

                                            так что кто выигрывает у пэхэпэ — это го это из коробки — без дополнительных костылей cluster и прочее.
                                            я уж не говорю по убогую инфраструктуру ноды жс — милионы модулей делающих какойто бред.
                                            и надо как то деплоить это
                                            а в го 1 бинарник без зависимостей

                                              +2
                                              так что кто выигрывает у пэхэпэ — это го это из коробки


                                              напишите статью для похапэшников о том:
                                              • как изолировать контексты запросов, что бы они не боялись "неумирающих вещей"
                                              • как эффективно дебажить
                                              • инкрементная пересборка, насколько просто вносить изменения и сколько приходится ждать и как это дело упростить (штуки вроде codegangsta/gin)


                                              Лично мне Go нравится, но говорить о том что это замена PHP я считаю пока рано… хотя кто его знает.
                                              я уж не говорю по убогую инфраструктуру ноды жс — милионы модулей делающих какойто бред.


                                              есть проблема хайпа и велосипедов. Но в целом в node комьюнити есть масса крутых библиотек. Как говорится если что-то еще не написано на JS то рано или поздно это будет написано на JS.
                                              а в го 1 бинарник без зависимостей


                                              с версии 1.5 можно же делать динамические библиотеки. Так что "линкуй все статически" это конечно весело но…
                                                +2
                                                > php выигрывает — более простой разработкой — после запроса умирает и очищается состояние — не нужно следить

                                                Какое состояние очищается?
                                                И за каким состоянием в ноде надо следить за которым в пхп не надо? Как это при написании кода проявляется?

                                                То что в пхп при каждом новом запросе все заново инициализируется — это по-моему скорее минус чем плюс.
                                                  0

                                                  Отсутсвие состояния — это минус? Наверное я отстал от жизни...

                                                    +1
                                                    Вы о чем?
                                                    Я говорю о том что на каждый запрос все по новой инициализируется, это для вас синоним «Отсутствия состояния»?

                                                    В сессии у вас что лежит?
                                                      +1

                                                      В сессии у меня лежат какие-то значения, но это лишь файлик (запись в редиске, etc), который можно подсунуть кому угодно.


                                                      Так же стоит различать полную инициализацию на стороне ядра и полную инициализацию на стороне языка. Если смотреть со стороны языка и его пользователя — да, на каждый запрос всегда чистые и пустые данные, обнулённые переменные и розовый сферообразный конь в вакууме, но если смотреть на способ работы — то висящий демон-процесс php-fpm (или несколько) и nginx, который подключается к нему unix sock — должны вам сказать о том, что вы не всё знаете о схеме работы пыха.


                                                      Или вы действительно считаете, что пых настолько быстрый, что холодный старт с поднятием полного стека окружения, чтения и парсинга исходников, генерации ast, генрации опкода (если есть соотв. опция в ini) и выполнения кода у него занимает сотую (~тысячную) долю секунды? Ну это тогда скорее комплимент. Хотя утверждение, действительно, не так уж и далеко от истины.

                                                        0
                                                        В сессии у меня лежат какие-то значения, но это лишь файлик (запись в редиске, etc), который можно подсунуть кому угодно.

                                                        В сессии у вас именно «состояние», пользователя, приложения, чего угодно.

                                                        Так же стоит различать полную инициализацию на стороне ядра и полную инициализацию на стороне языка. Если смотреть со стороны языка и его пользователя — да, на каждый запрос всегда чистые и пустые данные, обнулённые переменные и розовый сферообразный конь в вакууме но если смотреть на способ работы — то висящий демон-процесс php-fpm (или несколько) и nginx, который подключается к нему unix sock — должны вам сказать о том, что вы не всё знаете о схеме работы пыха.

                                                        Про кеширование мы речь не ведем, если вы об этом.
                                                        «Отсутствие состояния» — это вымышленный плюс, т.к. те данные, которые нужно сохранить между запросами — все равно придется как-то сохранять.
                                                        А для всего, что не вписывается в рамки «запрос — ответ» нужны дополнительные телодвижения (настройки в ини и прочее)
                                                        То есть PHP не «оберегает» разработчика, а только создает дополнительные неудобства.
                                                          +1
                                                          В сессии у вас именно «состояние», пользователя, приложения, чего угодно.

                                                          Ой, ну это уже демагогия. Такими темпами можно вообще утверждать, что ничего без состояния не существует. Даже "a = 23" — уже некое состояние. Подразумевался request — response воркфлоу, вы это прекрасно поняли, не передёргивайте =)


                                                          Хотя согласен, сессия — вполне себе некое состояние, так же как и любая запись в хранилище (БД к примеру), привязанная к пользователю (читай — клиенту).


                                                          Про кеширование мы речь не ведем, если вы об этом.

                                                          А кеш тут причём? о_0 Я о нём даже не заикался, а опкеш — это стандартный механизм внутренней оптимизации кода в пыхе, начиная с версии 5.4 (да ведь?), в 7.2, по планам, будет заменён (ну или дополнен) на JIT.


                                                          И на счёт вымышленности плюсов… Я понял, что вас не переспорить, т.к. просто мало (нет) опыта работы с пыхом, против, например джавы или хакса (соль-перец по вкусу).

                                                    +2
                                                    И за каким состоянием в ноде надо следить за которым в пхп не надо?

                                                    • соединение с базой данных — состояние, нам уже нужно держать пул соединений и самостоятельно все разруливать
                                                    • stateful сервисы (аунтентификация, сессии) — тут опять же нам нужно держать пул таких сервисов и отчищать после ответа или инициалировать их по новой на каждый запрос.
                                                    • переменные хранящие состояние и объявленные вне скоупа обработчика запросов. Ну мол типа глобальные в этом контексте.

                                                    А еще весело заниматься отладкой проблем возникающих только при конкурентных запросах.


                                                    Очень многие начинающие разработчики на node.js которые пришли скажем из фронтэнд комьюнити слишком привыкли к тому что stateful не вызывает проблем, и в итоге на сервере потом возникают весьма причудливые баги как только начинают приходить конкурентные запросы. (ну и тестят они в одиночку, а стало быть и проблем воспроизвести не могут).


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


                                                    то есть в этом плане PHP который подчищает за разработчиком после каждого запроса — это несомненно жирный плюс PHP и как по мне тот самый "понижатель пороха вхождения". Можно писать сколь угодно плохой код и он будет работать (до поры до времени). С другой стороны многие PHP разработчики уже перешли от умирающей модели выполнения к более-менее конкурентной на базе reactphp и похожих фреймворков. Конечно до производительности ноды там далеко, но разрыв значительно сокращается.


                                                    Ну и потом, в силу "синхронности" мы можем просто увеличить количество воркеров. Да, будет огромный оверхэд особенно в плане времени переключения контекста между процессами, но все же… дешево и сердито. И разработчики дешевые настолько что можно пару лишних серваков докупить на всякий случай. Ибо с дешевыми node.js разработчиками вероятность получить неподдерживаемое ведро макарон намного выше.

                                                      0
                                                      соединение с базой данных — состояние, нам уже нужно держать пул соединений и самостоятельно все разруливать

                                                      Почему самостоятельно? Для этого всего используются библиотеки. То что в PHP библиотеки встроены прямо в язык — это проблемы PHP. Никто на ноде не работает с базой «напрямую».

                                                      stateful сервисы (аунтентификация, сессии) — тут опять же нам нужно держать пул таких сервисов и отчищать после ответа или инициалировать их по новой на каждый запрос.

                                                      Зачем очищать или инициализировать по новой?

                                                      переменные хранящие состояние и объявленные вне скоупа обработчика запросов. Ну мол типа глобальные в этом контексте.

                                                      Ну и как туда может что-то «нечаянно» попасть? Если какие-то данные постоянно обрабатываются напрямую в памяти — то это осознанный выбор архитектуры приложения.
                                                      Вот вам код для самого простого модуля обработчика запросов.
                                                      Пожалуйста объясните что тут может пойти не так:

                                                      # -- my-module.js --

                                                      module.exports = (req, res) => {
                                                      let foo = 'bar';
                                                      // foo будет инициализироваться на каждый запрос
                                                      };

                                                      # -- EOF --


                                                      А еще весело заниматься отладкой проблем возникающих только при конкурентных запросах.

                                                      Каких проблем конкурентных запросов? Node однопоточна, что избавляет от проблем конкурентного доступа к данным на корню.

                                                      Очень многие начинающие разработчики на node.js которые пришли скажем из фронтэнд комьюнити слишком привыкли к тому что stateful не вызывает проблем, и в итоге на сервере потом возникают весьма причудливые баги как только начинают приходить конкурентные запросы. (ну и тестят они в одиночку, а стало быть и проблем воспроизвести не могут).

                                                      Вообще не понял о каких тестах речь. Нагрузочные тесты обычно проводят при помощи специальных программ.

                                                      Все то что я перечислил — это все легко и просто обходится. Полно готовых решений которые скрывают эти нюансы и ограничивают возможности разработчика в том что они могут делать.

                                                      Чем готовые решения ограничивают возможности? В крайнем случае всегда можно писать на «голом» апи.
                                                      Если мне в юнит тесте нужно проверить много одновременных вызовов какого-нибудь модуля — я беру и проверяю, и от того как это делается на фронт-энде это мало отличается.

                                                      то есть в этом плане PHP который подчищает за разработчиком после каждого запроса — это несомненно жирный плюс PHP и как по мне тот самый «понижатель пороха вхождения». Можно писать сколь угодно плохой код и он будет работать (до поры до времени). С другой стороны многие PHP разработчики уже перешли от умирающей модели выполнения к более-менее конкурентной на базе reactphp и похожих фреймворков. Конечно до производительности ноды там далеко, но разрыв значительно сокращается.

                                                      Ну и потом, в силу «синхронности» мы можем просто увеличить количество воркеров. Да, будет огромный оверхэд особенно в плане времени переключения контекста между процессами, но все же… дешево и сердито. И разработчики дешевые настолько что можно пару лишних серваков докупить на всякий случай. Ибо с дешевыми node.js разработчиками вероятность получить неподдерживаемое ведро макарон намного выше.

                                                      Я не понимаю почему все разговоры о производительности PHP сводятся к тому что на нем много дешевых и неопытных разработчиков?
                                                      Это факт, но речь же была не об этом…
                                                        +1
                                                        Зачем очищать или инициализировать по новой?

                                                        Каких проблем конкурентных запросов? Node однопоточна, что избавляет от проблем конкурентного доступа к данным на корню.

                                                        Вы серьёзно сейчас пытаетесь сравнивать один однопоточный сервер Node и один php-fpm с одноим воркером? Как только вы начинаете запускать Node cluster или несколько процессов на одном сервере или выходите за рамки одного сервера приходится заниматься всем этим, какую бы видимую простоту Node вам не сулила.

                                                          0
                                                          Чем готовые решения ограничивают возможности?

                                                          я говоню о этих ограничениях в положительном ключе. Это хорошие ограничения.

                                                    0
                                                    Go автоматом создает новые процессы для потоков (горутин), если сочтет нужным. В node.js можно перекинуть отдельное действие только на другой процесс. На сколько одно эффективнее другого — без понятия.
                                                    +3
                                                    никто не запрещает замутить кластер с нодой, тогда будет сколько вам угодно потоков

                                                    если, к примеру, использовать кластер для http-сервера, то запросы будут распределяться между потоками по алгоритму Round Robin
                                                      0
                                                      замутить можно что угодно. вопрос в целесообразности.

                                                      — в PHP это уже есть, сложившаяся годами архитектура на воркерах веб сервера со времен зарождения PHP

                                                      — в go такие костыли просто не нужны
                                                        0
                                                        в PHP это уже есть, сложившаяся годами архитектура на воркерах веб сервера со времен зарождения PHP

                                                        Ну так уж и годами. С 5.3.3 только в стандартной поставке.
                                                          0
                                                          А причем тут 5.3.3 (с момента выхода которого, кстати, прошло 6 лет уже)?
                                                          А mod_php, которому уж точно сто лет в обед, на таком же принципе работает. Так что да, годами.
                                                            0

                                                            mod_php работает на простом принципе. Берем HTTP запрос и дергаем PHP скрипт. никаких воркеров.


                                                            Воркеры это часть архитектуры апача. И между прочим в Go примерно то же самое выходит если мы хотим организовать горячую подмену кода.

                                                              0
                                                              Верно, но это не отменяет того факта, что работа на процессах-воркерах это уже очень давно сложившийся принцип у PHP. Я только лишь это и имел в виду.
                                                                0

                                                                В go что-ли не так? Ну хорошо, распределением по "воркерам" занимается сам рантайм языка. Это координально что-то меняет?


                                                                К примеру для PHP есть еще такой "кастыль": https://github.com/php-pm/php-pm

                                                                  0
                                                                  Про go я вообще ничего не говорил). Мое сообщение было всего лишь небольшим замечанием к
                                                                  этому комментарию
                                                                    0

                                                                    Извиняюсь. Что-то я с утра не внимательный.

                                                          +2
                                                          в go такие костыли просто не нужны

                                                          как вы организовываете zero-downtime деплоймент с go, коль кастыли эти в виде отдельных процессов воркеров не нужны? Придерживаете коней (у нас же полностью ресурсы машины утилизируются, так?), поднимаете новую версию апы, тушите старую и отпускаете коней?


                                                          То есть как с кастылями на воркерах на горячую подменять не выйдет?

                                                      +2
                                                      Высокая скорость обработки запроса скорее всего упрется в относительно низкую скорость HTTP. И, если скорость работы сервака можно тупо увеличить более мощным железом, которое нынче копейки стоит, то скорость передачи от нас мало зависит.
                                                      Что касается асинхронки. Польза очевидна если надо отправить почту или записать лог. Но в большинстве случаев программа должна дождаться окончания операции и вернуть результат иначе данные могут потерять консистентность. С этой точки зрения операция синхронна и то, что длительную операцию выполняет другой поток или event сути дела не меняет
                                                      Преимущество ноды в основном если надо отправить много мелких ответов, например месажи в соцсетях — создавать каждый раз контекст страницы как в PHP для отправки пары килобайт действительно громоздко. Но таких сайтов — подавляющее меньшинство.
                                                      ИМХО — преимущества ноды сомнительны а трудоемкость разработки очевидно выше (напомню что труд програмиста нынче гораздо дороже железа). Попросту говоря нода предназначена для работы в определенной узкой нише не более того.

                                                      .
                                                        +1
                                                        то, что длительную операцию выполняет другой поток или event сути дела не меняет

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

                                                        для отправки пары килобайт действительно громоздко. Но таких сайтов — подавляющее меньшинство.

                                                        кхм, а большинство REST апи — разве не именно это? Oтправляют всего по несколько килобайт на каждый запрос, и часто вообще ничего кроме заголовков не отправляют.

                                                        ИМХО — преимущества ноды сомнительны а трудоемкость разработки очевидно выше (напомню что труд програмиста нынче гораздо дороже железа)

                                                        очень спорное утверждение, почему на ноде сложность «очевидно» выше? В чем именно выражаются трудности?
                                                          –1
                                                          Если в этот же процесс придет еще один запрос

                                                          то что нода пихает новый запрос в тот же процесс — проблема ее архитектуры. Точнее особенность архитектуры полезная для отправки много мелких сообщений.
                                                          Не надо использовать ноду куда она не подходит.

                                                          а большинство REST апи — разве не именно это?

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

                                                          очень спорное утверждение, почему на ноде сложность «очевидно» выше

                                                          сравните с PHP который в отличие от яваскрипта изначально заточен на серверную обработку.

                                                            +1
                                                            Там и гигабайты могут передаватся зависит от прикладной задачи


                                                            Сейчас тренды — мобильные приложения. Даже если вы пишите API не для мобилок, добрая половина трафика сейчас с мобилок. А стало быть подавляющее большинство старается уложиться в желаемые 50Кб на респонс.
                                                            сравните с PHP который в отличие от яваскрипта изначально заточен на серверную обработку.


                                                            javascript изначально заточен под I/O bound задачи, а для web это 90% всех задач. PHP же заточен под сайтики, он stateless и т.д. 10 лет назад у него небыло конкурентов, сегодня "изоляции" можно добиться другими способами. Но соглашусь что уровень разработчика в среднем для ноды должен быть выше.

                                                            Техническая возможность причем сделать все что угодно есть и у одного и у другого языка.

                                                            p.s. работаю и с похапэ (основной язык) и с нодой.
                                                              +1
                                                              то что нода пихает новый запрос в тот же процесс — проблема ее архитектуры. Точнее особенность архитектуры полезная для отправки много мелких сообщений.
                                                              Не надо использовать ноду куда она не подходит.

                                                              Почему эта архитектура, по-вашему, не подходит для отправки много больших сообщений?

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

                                                              «подавляющему большинству небольших сайтов не нужно никакое апи» — так правильнее.
                                                              На дворе 2016 год, большинство современных веб проектов движутся в сторону одностраничных приложений.
                                                              Т.е. гонять по сети мегабайты ХТМЛ — это не нормальная ситуация для текущих тенденций в разработке.

                                                              Если брать абсолютные цифры — то большинство сайтов это обычные блоги на вордпрессе и т.п. где «работой программиста» вообще не пахнет.
                                                              Но мы же с вами про профессиональную разработку говорим?

                                                              сравните с PHP который в отличие от яваскрипта изначально заточен на серверную обработку.

                                                              Мы вроде сравниваем node с php как платформы, а не как языки программирования.
                                                              node тоже изначально заточена на серверную разработку, разве не так?
                                                                0
                                                                Почему эта архитектура, по-вашему, не подходит для отправки много больших сообщений?
                                                                потому что в этом случае нет никаких преимуществ перед более простым для разработки PHP

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

                                                                Это даже близко не так. Да, есть мода на SPA. Но SPA не дает никаких преимуществ для пользователя — ему пофиг как там сделано. Но SPA однозначно более трудоемкие в разработке. Уж поверьте — как раз приходится сопровождать после любителей модных фишек проект сделаный на Flex.
                                                                Т.е. гонять по сети мегабайты ХТМЛ — это не нормальная ситуация для текущих тенденций в разработке.

                                                                текущие тенденции — это тестирование сетей 5G. Повышать стоимость разработки экономя на трафике и перегружая мобильные браузеры яваскриптовыми фреймворками — уж точно ненормально. Да и нет в нормально сделанном сайте (flat desidn и google style рулят) мегабайтов HTML.

                                                                node тоже изначально заточена на серверную разработку, разве не так?

                                                                Нода изначально заточена на обработку множества мелких сообщений которые обрабатываются в одном потоке. В этом и был смысл. Все остальное — от лукавого.
                                                                Это типа как вордпрес, который изначально заточен на блоги но фанаты умудряются делать на нем интернет-магазины.

                                                                  +1
                                                                  потому что в этом случае нет никаких преимуществ перед более простым для разработки PHP

                                                                  Преимущество node — скорость. И пожалуйста, объясните чем PHP «проще» для разработки?
                                                                  Еще раз повторю, что мы говорим про простоту в использовании для профессионального разработчика, а не для любителя.
                                                                  (Например, в PHP «нативно» поддерживается работа с MySQL, но зато нету пакетного мэнеджера из коробки и нужны «дополнительные заморочки» если требуется работа с сокетами, и т.д..)

                                                                  Это даже близко не так. Да, есть мода на SPA. Но SPA не дает никаких преимуществ для пользователя — ему пофиг как там сделано. Но SPA однозначно более трудоемкие в разработке. Уж поверьте — как раз приходится сопровождать после любителей модных фишек проект сделаный на Flex.

                                                                  Простите, но «на слово» не поверю, приводите аргументы. Сам сопровождал как «традиционные» проекты, так и SPA — не могу сказать что трудозатраты сильно отличаются.
                                                                  С Flex'ом никогда не работал, и это скорее исключение, абсолютное большинство веб приложений пишется на HTML5

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

                                                                  текущие тенденции — это тестирование сетей 5G.

                                                                  Точно, скажите это подальше от центра.
                                                                  И исходящий от сервера трафик тоже никто не считает…

                                                                  Повышать стоимость разработки экономя на трафике и перегружая мобильные браузеры яваскриптовыми фреймворками — уж точно ненормально.

                                                                  А жрать деньги клиента на трафике — это нормально?
                                                                  Я понимаю, что вам возможно в плане бизнеса пофиг на то, сколько данных туда-сюда ходит, но поверьте это точно не повод для гордости в современной веб-разработке.

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

                                                                  А веб-сервер — это разве не обработка множества мелких сообщений от клиентов??

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

                                                                  Это нифига не как «вордпрес», node отлично подходит для огромного количества типов проектов, в том числе для магазинов и т.п.
                                                                    +1
                                                                    SPA не дает никаких преимуществ для пользователя — ему пофиг как там сделано.

                                                                    Для пользователей мобильного интернета важно. Ему бы хотелось экономить трафик.

                                                                    SPA однозначно более трудоемкие в разработке.

                                                                    Спорное утверждение. Сохранение состояния отдельных html-элементов легче решать в SPA приложении, чем в «не-SPA». Бэкенд тут уже можно выбирать на свое усмотрение. Хоть на php.
                                                                      –1
                                                                      Преимущество node — скорость.

                                                                      при использовании ноды в той нише для которой она предназначена.

                                                                      Еще раз повторю, что мы говорим про простоту в использовании для профессионального разработчика, а не для любителя.

                                                                      не помню что бы мы вообще упоминали какой разработчик. Не надо подтасовывать дискусию под свои аргументы. Порог вхождения в PHP однозначно ниже.
                                                                      в PHP «нативно» поддерживается работа с MySQL,

                                                                      в PHP нативно поддерживается 99% процентов того для чего в ноде нужен пакетный менеджер.
                                                                      нету пакетного мэнеджера из коробки

                                                                      Composer вполне справляется.
                                                                      А веб-сервер — это разве не обработка множества мелких сообщений от клиентов??

                                                                      по моему вы смутно понимаете изначальный смысл ноды и ее отличие от других вебсервероо.
                                                                      Для пользователей мобильного интернета важно. Ему бы хотелось экономить трафик.

                                                                      Гораздо более ему бы хотелось чтобы страницы не тупили за каждым телодвижением изза клиентского яваскрипта.
                                                                      А трафик на мобиле в основном жрет медиаконтент а не HTML. Не говоря уже про приложения на андроиде постоянно лазающие в инет.

                                                                      Сохранение состояния отдельных html-элементов легче решать в SPA приложении, чем в «не-SPA»

                                                                      Если использовать вменяемый бекенд а не MVC то никаких проблем с сохранением состояния нет. Лично у меня точно — для того и написал свой фреймворк.

                                                                        +1
                                                                        по моему вы смутно понимаете изначальный смысл ноды и ее отличие от других вебсервероо.

                                                                        Нет, по-моему это вы не понимаете, что за 7 лет с тех пор как вышла node в веб-разработке многое изменилось и она применяется для гораздо более широкого круга задач чем просто «чатики»

                                                                        не помню что бы мы вообще упоминали какой разработчик. Не надо подтасовывать дискусию под свои аргументы.

                                                                        Я ничего не подтасовываю, зачем вообще обсуждать разработчиков, которые не осилили порог вхождения?
                                                                        Если вы набираете вчерашних студентов или дешевых фрилансеров — согласен — PHP ваш лучший выбор, но более продвинутых разработчиков, на мой взгляд, не должен останавливать порог вхождения.

                                                                        в PHP нативно поддерживается 99% процентов того для чего в ноде нужен пакетный менеджер.

                                                                        Ага, и постоянно таскается за собой в виде миллиона хаотично названных функций в глобальном пространстве имен.
                                                                        (А еще там только только появилась нормальная поддержка Юникода)
                                                                        Кроме того, некоторые вещи, которые в node есть из коробки (сокеты и т.п.) в PHP требуют танцев.

                                                                        Гораздо более ему бы хотелось чтобы страницы не тупили за каждым телодвижением изза клиентского яваскрипта.

                                                                        Покажите мне «тупящее» одностраничное приложение, и схожее по функционалу, не «тупящее» классическое.
                                                                          0
                                                                          Ага, и постоянно таскается за собой в виде миллиона хаотично названных функций в глобальном пространстве имен

                                                                          Это хоть как-то мешает?

                                                                          (А еще там только только появилась нормальная поддержка Юникода)

                                                                          Ээээ… это какая такая «нормальная поддержка Юникода» появилась в PHP «только только», не подскажите? Поддержки юникода в ядре PHP нет, не было и, похоже, не будет. Все задачи, связанные с юникодом, прекрасно решаются расширениями уже давным-давно.

                                                                            +1
                                                                            Это хоть как-то мешает?

                                                                            Конечно, делает работу с языком менее удобной.
                                                                            Если какая-то функция станет не актуальной (например как mysql_*) — вам придется переписывать приложение, вместо того чтобы просто обновить библиотеку.
                                                                            Вообще в подходе «весь функционал языка в виде миллиона глобальных функций» я вижу только минусы.
                                                                            Плюс от экономии времени (мол, не нужно никаких библиотек подключать, просто фигачишь прямо на языке) — для меня лично сомнителен, больше похоже на «медвежью услугу».

                                                                            Насчет юникода — прошу прощения, ошибся, действительно в седьмой версии он до сих пор не поддерживается полностью.
                                                                            В чем заморочки? В том, что например, в той же node — мне вообще никогда не нужно думать об этом. Все строки по умолчанию UTF8 с полной поддержкой юникода. String.length никогда не вернет мне неверную длину.
                                                                          +2
                                                                          А трафик на мобиле в основном жрет медиаконтент а не HTML.

                                                                          А вот это как раз сильно зависит от приложения.
                                                                          Например, если посмотреть эту страницу (а хабр не является одностраничным приложением), то видно что большая часть трафика — это как раз JS/HTML/CSS

                                                                          (кликабельно)

                                                                          И есть еще куча ресурсов где медиа контент не является основным.
                                                              +1
                                                              В чём причина отставания V8 от Oracle Java в скорости работы вычислительных алгоритмов, например, числодробилок (т.е. когда GC не вмешивается)?
                                                              Эта причина временная или фундаментальная? Связано ли она с типизацией языков?
                                                              При первом приближении (если не брать во внимание то, что у V8 вообще нет интерпретатора) обе реализации работают примерно одинаково — ищут «горячие» участки кода и более тщательно оптимизируют их. Почему тогда несмотря на «миллионы гугла» за много лет оптимизатор V8 так и не приблизился к HotSpot? Понятно, что HotSpot это вроде как state of art, но именно V8 (иногда вместе с LuaJIT) хоть как-то могут противопоставить свой JIT продукту Oracle.
                                                              Хотелось бы, конечно, узнать ответ от mraleph, но любой приму с благодарностью.
                                                                +2
                                                                В чём причина отставания V8 от Oracle Java в скорости работы вычислительных алгоритмов, например, числодробилок


                                                                Динамические языки оптимизировать очень сложно. В Java вся необходимая информация для оптимизаций доступна на этапе компиляции, в JS же компиляция происходит по сути в рантайме. оптимизирующий компилятор входит в бой только для горячего кода, который выполняется очень часто (так как оптимизация и анализ кода весьма дорогая операция насколько я понимаю).

                                                                Так же насколько я помню JVM умеет такие маленькие радости как автоматическая векторизация вычислений, чего в ноде пока нет, хоть и есть проекты вроде simd.js.

                                                                В целом же есть еще такие штуки как asm.js или webassembly которые могут быть аналогом JNI для java.
                                                                  0
                                                                  Какая именно информация есть у HotSpot, но нет у V8?
                                                                  А если использовать TypeScript — у не го вроде типы можно декларировать?
                                                                  JNI вообще не о том.
                                                                    0
                                                                    TypeScript потом транслируется в JS, так что он делу не поможет.

                                                                      +1
                                                                      Какая именно информация есть у HotSpot, но нет у V8?


                                                                      информация о типах и структурах данных. В силу того что javascript динамический язык (то есть мы можем любую структуру менять в рантайме) оптимизирующий компилятор должен это учитывать. Поменялись структуры — нужно перегенерить код. Если структуры не меняются, если все относительно статично — то V8 будет генерировать очень эффективный код.

                                                                      Если хотите, можете послушать неплохую лекцию на тему того как работает JIT в V8: https://www.youtube.com/watch?v=Z_q6iw3h48s
                                                                      А если использовать TypeScript — у не го вроде типы можно декларировать?


                                                                      Информацию о типах TypeScript использует исключительно в целях статического анализа, на рантайм это никак не влияет. С другой стороны это ограничивает разработчика в том какой трэш он может творить и по идее мы придем к относительно стабильным структурам данных и V8 опять же сможет это все красиво оптимизировать.
                                                                      JNI вообще не о том.


                                                                      JNI о том, зачем извращаться если можно реализовать какой-то критичный алгоритм на Сях и получить сразу эффективный код?
                                                                    0

                                                                    Потому что динамические языки оптимизировать куда сложнее, а ещё потому что миллионы долларов, вбуханные ораклом в хотспот ;)

                                                                    +1
                                                                    Offtop: «Cranshaft состоит из двух компонентов: Hydrogen и Lithium.» Куда дели Helium?
                                                                      +1
                                                                      На многих языках есть реализация EventLoop-а: Ruby и EventMachine, C и Nginx, Pyton и Tornado, JavaScript и Nodejs, и тд. И у всех одна ниша применимости (как выше и писали): много i/o запросов, упирающихся в ожидание ответа сети/диска/сервиса, а не в процессор. С девизом «Никогда не останавливаем(не блокируем) цикл».
                                                                      Ну и нода не самая быстрая реализация этого подхода. Хотя кому по душе JavaScript, то пойдёт.
                                                                        +1
                                                                        Развели тут срач обсуждение, а ведь можно же ещё на Scala + Play Framework писать.
                                                                          +3

                                                                          Вы хотели сказать Kotlin ;)


                                                                          Писать можно на чем угодно. А холивары это весело и забавно)

                                                                          0
                                                                          Писал я парсер сначала на php, потом переписал на nodejs. Парсер должен был скачивать/обрабатывать более 30к записей. С php намучился(потреблял дикое кол-во памяти, падал и обрабатывала за раз меньшее кол-во записей), нода приятно улыбнула(время работы 1-1.2час).
                                                                            +1

                                                                            Было бы намного интереснее сравнить вашу реализацию на PHP и на Node. Ибо я могу себе представить реализацию на PHP которая работает не сильно хуже и не сильно медленнее, ну и опять же могу представить себе ужасную синхронную лапшу.

                                                                              0
                                                                              Увы я не могу показать код, жаль. Но могу сказать — php реализация асинхронна.
                                                                                0
                                                                                Асинхронно тоже можно сделать по разному. Между, скажем, select() и epoll() разница в производительности может быть очень сильно заметна.

                                                                                Я сравнивал производительность node.js и reactphp+ext/event — reactphp получился медленнее в полтора раза, причем это был совершенно искусственный тест типа «отдать hello world», и это был php 5.6. На реальных задачах разница будет меньше.
                                                                              +2
                                                                              писал парсеры на .net, java, scala и на ноде

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

                                                                              стоит также отметить, что с использованием Promise код становится весьма компактным и читабельным
                                                                                +1
                                                                                стоит также отметить, что с использованием Promise код становится весьма компактным и читабельным

                                                                                Добавлю также что на ноду можно и нужно писать на typescript, но даже если нет — async/await и бабель, но хейтеров это не остановит — они будут продолжать пинать яваскрипт нулевых годов также как хейтеры пыха пинают четвертый пых, не обращая внимания на реалии.

                                                                            Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.

                                                                            Самое читаемое