Предлагаем вам перевод статьи Евгения Обрезкова, в которой он кратко и по делу рассказывает о причинах высокой скорости 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 коду.
Только после этого, оптимизированный код может заменить старый неоптимизированный и продолжить выполнять ваше приложение намного быстрее.
Полезные ссылки
Комментарии (103)
yjurfdw
27.06.2016 15:05-10Не совсем понимаю, почему nodeJS сравнивают с php. Для меня nodeJS больше к фронтенду отношения имеет, нежели к бекенду, как на картинке:
Картинка
youlose
27.06.2016 15:11+7Чатики сложнее чем бложики писать.
yjurfdw
27.06.2016 15:19А я про бложики и не говорю :)
Многие хвалят ноду в контексте «убийцы PHP», но я ни разу не видел пример реализации высоконагруженного бекенда с какой то бизнес-логикой.
Фронтенд да, делают и вроде все хорошо. А про бекенд только разговоры и сомнительные сравнения.
gearbox
27.06.2016 16:37+7но я ни разу не видел пример реализации высоконагруженного бекенда с какой то бизнес-логикой.
Достаточно нагружен? https://www.netflix.com Да, на ноде — http://techblog.netflix.com/2014/11/nodejs-in-flames.html
eoffsock
27.06.2016 17:49Cowboy+bullet с вами не согласятся.
lucky_libora
27.06.2016 23:51пхп не убьешь, учитывая кол-во сайтов на Drupal, Joomla и прочих CMS
foxmuldercp
28.06.2016 10:46+1Вот первые два точно стоит убить. вместе с битриксом, а тот же Вордпресс чем дальше тем светлее, судя по слова моих знакомых разработчиков.
Извините, по моей статистике работы на двух хостингах в вп проблема в кривых/украденных плагинах/темах, а в первых Ваших двух указанных — проблема в ядре. Если брать мою субьективную статистику проломанных сайтов на всех моих хостингах, Вп ломают сильно меньше, чем жумлу/друпал, даже при том, что половина вордпрессиков на хостингах ещё тех версий которые не умеют автообновления
ErickSkrauch
27.06.2016 15:22На скриншоте изображена какая-то дичь. Судя по нему, нода выступает как прокси для доступа к бэкэнду (там должен быть Nginx в таком случае).
Я писал на Node.js бота, выставлял к нему REST API через Express и это всё отлично работает по сей день. REST можно было пользоваться как с PHP бэкэнда, так и прямо с клиента. У ноды есть достаточно шаблонизаторов, чтобы обеспечивать и полноценные сайты с интерфейсом.yjurfdw
27.06.2016 15:27+1Почему же дичь, картинка отсюда: https://habrahabr.ru/post/197358/
ErickSkrauch
27.06.2016 15:32Так вот же и обсуждение оттуда же: https://habrahabr.ru/post/197358/#comment_6845970
Конечно, я не писал на Node.js большие проекты (какие писал на PHP), но считаю, что написать на Node.js большой проект не составит большего труда (при должном знании языка, конечно), чем сделать это на PHP. Использовать Node.js в качестве прокси-шаблонизатора — кощунство. В конце-концов, мы живём в 2016 году, когда ReactJS и Angular как раз и диктуют требования писать backend как REST API.symbix
27.06.2016 15:48Мне кажется, тут все зависит от того, что считать большим проектом. И дело тут не в самом Node.js, а в инфраструктуре.
Если речь идет о большом монолитном проекте с массой бизнес-логики, то тут Node.js просто не предоставляет достаточно подходящего фреймворка, позволяющего писать ООП-код в SOLID/DDD-стиле (про сам язык Javascript ничего не говорю — тут Typescript все вопросы решает). Самое принципиальное — отсутствие Data Mapper ORM; все, что я видел (и даже содержит в названии или описании слова data mapper), по сути вариации на тему Active Record.
Если же применять микросервисную архитектуру, бизнес-логики немного и все сводится к CRUD, то без разницы — и для PHP, и для Node.js есть хорошие инструменты, при этом у Node.js есть некоторое преимущество в возможном code reuse на клиенте и сервере. Это хорошо, но не всегда подходит.
vgoloviznin
27.06.2016 17:49Что такое полноценный бэкенд? :)
Мы используем ноду на бэке в некоторых местах и проблем пока особо не наблюдается
em92
27.06.2016 17:49Есть у кого нибудь опыт написания полноценного бекенда на ноде?
Писал браузер игровых серверов Quake Live. Данные о серверах хранятся в виде словаря «адрес — состояние» (в состояние входит название сервера, режим игры, количество игроков и т.п.). Сам словарь представлен, как обычная переменная, т.к. памяти для 1000 серверов хватает. Все состояния успевают обновляться примерно за минуту. И все это на node.js.
На бэкенде выдает статические файлы и данные в формате json. Фронтенд — это html + браузерный js.
Staltec
27.06.2016 19:45+2Уже пятый год у моего клиента работает система информатизации производственных процессов на оконном производстве (евроокна). Задачи системы:
— демонстрация технологических карт изделий на участках конвейера;
— фиксирование операций с изделиями;
— предоставление в реальном времени данных о состоянии отдельных изделий и в целом состояния производства;
— аналитика выработки на участках и конкретными сотрудниками;
— учёт контроля качества;
— складской учёт готовых изделий и стеклопакетов;
— планирование графика отгрузки со склада;
— автоматическое уведомление клиентов о готовности заказа по SMS;
Все интерфейсы системы реализованы как реалтайм веб-приложения использующие Socket.io.
Система писалась на NodeJS версии 0.6, потом была переведена на 0.8 и сейчас уже на 0.12. С переходом проблем не было.
Максимальный аптайм NodeJS процесса системы который удалось наблюдать — более 200 дней. Утечек памяти за это время не зафиксировано.
DexterHD
27.06.2016 15:12+6Как V8 оптимизирует ваш код?
А где подобный раздел о том, как это делает PHP? Очередная статья из категории «Я знаю много о node.js но понятия не имею ни чего о внутренностях PHP».
Fesor
27.06.2016 22:12+2А где подобный раздел о том, как это делает PHP?
А PHP просто не оптимизирует код в рантайме. Ну то есть вообще. Все оптимизации происходят только на уровне парсинга исходников, в то время как в nodejs "горячий" код прогоняется оптимизирующим компилятором и в итоге мы можем получить весьма эффективный машинный код.
maxru
27.06.2016 15:13+6PHP не имеет JIT компилятора.
Если нужен JIT — используйте HHVM. Впрочем, PHP 7.x и без JIT приблизилась по скорости к hhvm, при этом «jit capability» в движке 7 есть.
tgz
27.06.2016 15:49-5У ноды один плюс в сравнении с похапе — это вебсокеты. Но при это оба отстают на бесконечность от го.
vlreshet
27.06.2016 16:32+3Кхм-кхм Сокеты в PHP
alexkunin
27.06.2016 16:35Это же совсем другие сокеты.
vlreshet
27.06.2016 16:38+2Ну привет. Как это другие? Я лично строил чатик на вебсокетах с php в роли сокет-сервера. Потом, правда, переписал всё на nodejs, он получше заточен под сокеты, но! Клиентскую часть никак не менял. Это точно те же самые сокеты как и на ноде.
gearbox
27.06.2016 16:41-5возможно я ошибаюсь — вы точно вебсокеты с беркли сокетами не путаете? Вебсокеты — это надстройка над вторым http.
alexkunin
27.06.2016 16:42+1Вы залинковали BSD Sockets — это TCP, UDP или сырые сокеты, довольно низкоуровневая штука. А WebSocket — это «надстройка» над TCP, которая позволяет отправлять-принимать сообщения (сам-то TCP потоковый, а не message-oriented).
Т.е. между приведенными вами сокетами и вебсокетами должна находиться еще реализация вебсокетов. Например, Ratchet.vlreshet
27.06.2016 16:46+1Посыпаю голову пеплом. Года два назад игрался, забыл как оно было. Поверх этих сокетов писал реализацию именно web-сокетов, «с коробки» их действительно нет.
spmbt
27.06.2016 16:18+2—Пациент, что вы видите, глядя на программу, написанную на NodeJS?
—Женщину в спортивной одежде, очень быстро бегущую.
artyfarty
27.06.2016 16:24+8И где вся эта невероятная скорость, когда делаешь npm install?
cy-ernado
27.06.2016 16:37npm install тормозит скорее из-за того, что принято даже очень небольшие сущности выносить в модуль.
Зато графики по количеству модулей красивые и всех обгоняют.artyfarty
27.06.2016 16:42+2NPM во всём проигрывает композеру (ну разве что кроме того что модульность JS позволяет избежать конфликта версий пакетов). npm shrinkwrap отвратителен в сравнении с lock-файлами композера или bundler. NPM 3 медленнее NPM2. Все попытки заменить сам NPM на более быстрый загрузчик пока к сожалению не продакшен-реди. Наличие native extensions не позволяет в отчаянии взять и запаковать node_modules в реп.
Композер же шустрый (особенно если одни только zipballs качает, распараллеливающий плагин тоже вполне рабочий).
А то что самих пакетов много – это уже дело десятое.
Fedcomp
28.06.2016 09:59+1Ну и у composer нет native extensions. Финиш.
Fesor
28.06.2016 11:54https://github.com/composer/composer/pull/2898
Но это просто к тому что все можно сделать. Как минимум на хуках дергать pecl install. Я считаю npm более "законченным" продуктом.
AndreyRubankov
27.06.2016 17:06+23NodeJS однопоточна и асинхронна. Любая операция ввода-вывода не блокирует работу. Это значит, что ты можешь читать файлы, отправлять электронные письма, запрашивать базу данных и совершать другие действия… одновременно.
Вот любят возводить преимущества асинхронности в абсолют и совсем не обращать внимание на нюансы!
Асинхронность дает преимущество только для 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, ни кешей.
У каждого из них свой путь чем-то лучше, чем-то хуже!
AterCattus
27.06.2016 20:39+1А в node.js под linux чтение файла при нагруженном диске ставит колом весь поток (единственный?) node.js?
lucky_libora
27.06.2016 22:55+1нет, для чтения файлов и других I/O операций используется ThreadPool, ответа от которого ждет непосредственно сама нода. А пока она ждет, может заняться другими вещами
IvanPanfilov
27.06.2016 21:15-7да говнонода асинхронная. но она однопоточная и динамически типизируемая — поэтому необходимо делать дополнительные проверки и следить что не текло.
в отличии от пыхапе — который умирает осле исполнения запроса — меньше траха с соблюдением состояния приложения.
приимуществ у nodejs перед php нет.
вот Go — это круто — там и типизация и горутины с автомасштабирование по процессам и коллбеков нету и костыли не нужны типа async await — которые хоть как то уменьшают боль от неправильной архитектуры «асинхронности» nodejs.Fesor
27.06.2016 21:25+2да говнонода асинхронная. но она однопоточная и динамически типизируемая
а PHP не динамически типизируем? Если вам не хватает информации о типах — https://flowtype.org/ и все хорошо. Для статического анализа все что нужно есть (и получше чем в PHP) а в рантайме это обычно уже и не нужно. Ну и не стоит забывать что система типов в JS чуууть лучше чем в PHP.
приимуществ у nodejs перед php нет.
ошибаетесь) Это я вам как похапэшник заявляю.
вот Go — это круто — там и типизация и горутины с автомасштабирование по процессам
по процессам или потокам? Мне как-то казалось что по потокам. Ибо если по процессам: https://nodejs.org/api/cluster.html — ровно то же самое по сути. Просто не так "прозрачно" для разработчика.symbix
27.06.2016 23:28А, кстати, схему «мастер работает рутом, а детки дропают привелегии» в этом кластере до сих пор так и не сделали, или я плохо смотрю?
Во времена ноды то ли 0.2, то ли 0.3 был доступен posix api, на нем я легко и быстро повторил классическую юникс-схему, по которой работает тот же nginx, и спокойно себе слушал 80-й порт. Потом posix api зачем-то выбросили, кажется, это случайно совпало с чемоданом денег из Microsoft, после которого сразу заговорили о кроссплатформенности, которая свелась к тому, что posix-вызовы выкинули, а замену — ну… как-нибудь потом. С тех пор, так сказать, осадочек остался.
IvanPanfilov
28.06.2016 07:21я кто му что нет разницы php нода жс или еще какйото скриптовой язык
php выигрывает — более простой разработкой — после запроса умирает и очищается состояние — не нужно следить
в остальных динамических языках сложнее — а профита практически нет.
так что кто выигрывает у пэхэпэ — это го это из коробки — без дополнительных костылей cluster и прочее.
я уж не говорю по убогую инфраструктуру ноды жс — милионы модулей делающих какойто бред.
и надо как то деплоить это
а в го 1 бинарник без зависимостей
Fesor
28.06.2016 09:45+2так что кто выигрывает у пэхэпэ — это го это из коробки
напишите статью для похапэшников о том:
- как изолировать контексты запросов, что бы они не боялись "неумирающих вещей"
- как эффективно дебажить
- инкрементная пересборка, насколько просто вносить изменения и сколько приходится ждать и как это дело упростить (штуки вроде codegangsta/gin)
Лично мне Go нравится, но говорить о том что это замена PHP я считаю пока рано… хотя кто его знает.
я уж не говорю по убогую инфраструктуру ноды жс — милионы модулей делающих какойто бред.
есть проблема хайпа и велосипедов. Но в целом в node комьюнити есть масса крутых библиотек. Как говорится если что-то еще не написано на JS то рано или поздно это будет написано на JS.
а в го 1 бинарник без зависимостей
с версии 1.5 можно же делать динамические библиотеки. Так что "линкуй все статически" это конечно весело но…
YemSalat
28.06.2016 11:29+2> php выигрывает — более простой разработкой — после запроса умирает и очищается состояние — не нужно следить
Какое состояние очищается?
И за каким состоянием в ноде надо следить за которым в пхп не надо? Как это при написании кода проявляется?
То что в пхп при каждом новом запросе все заново инициализируется — это по-моему скорее минус чем плюс.
SerafimArts
05.07.2016 00:15Отсутсвие состояния — это минус? Наверное я отстал от жизни...
YemSalat
05.07.2016 06:01+1Вы о чем?
Я говорю о том что на каждый запрос все по новой инициализируется, это для вас синоним «Отсутствия состояния»?
В сессии у вас что лежит?SerafimArts
05.07.2016 12:01+1В сессии у меня лежат какие-то значения, но это лишь файлик (запись в редиске, etc), который можно подсунуть кому угодно.
Так же стоит различать полную инициализацию на стороне ядра и полную инициализацию на стороне языка. Если смотреть со стороны языка и его пользователя — да, на каждый запрос всегда чистые и пустые данные, обнулённые переменные и розовый сферообразный конь в вакууме, но если смотреть на способ работы — то висящий демон-процесс php-fpm (или несколько) и nginx, который подключается к нему unix sock — должны вам сказать о том, что вы не всё знаете о схеме работы пыха.
Или вы действительно считаете, что пых настолько быстрый, что холодный старт с поднятием полного стека окружения, чтения и парсинга исходников, генерации ast, генрации опкода (если есть соотв. опция в ini) и выполнения кода у него занимает сотую (~тысячную) долю секунды? Ну это тогда скорее комплимент. Хотя утверждение, действительно, не так уж и далеко от истины.
YemSalat
05.07.2016 14:26В сессии у меня лежат какие-то значения, но это лишь файлик (запись в редиске, etc), который можно подсунуть кому угодно.
В сессии у вас именно «состояние», пользователя, приложения, чего угодно.
Так же стоит различать полную инициализацию на стороне ядра и полную инициализацию на стороне языка. Если смотреть со стороны языка и его пользователя — да, на каждый запрос всегда чистые и пустые данные, обнулённые переменные и розовый сферообразный конь в вакууме но если смотреть на способ работы — то висящий демон-процесс php-fpm (или несколько) и nginx, который подключается к нему unix sock — должны вам сказать о том, что вы не всё знаете о схеме работы пыха.
Про кеширование мы речь не ведем, если вы об этом.
«Отсутствие состояния» — это вымышленный плюс, т.к. те данные, которые нужно сохранить между запросами — все равно придется как-то сохранять.
А для всего, что не вписывается в рамки «запрос — ответ» нужны дополнительные телодвижения (настройки в ини и прочее)
То есть PHP не «оберегает» разработчика, а только создает дополнительные неудобства.SerafimArts
05.07.2016 16:02+1В сессии у вас именно «состояние», пользователя, приложения, чего угодно.
Ой, ну это уже демагогия. Такими темпами можно вообще утверждать, что ничего без состояния не существует. Даже "a = 23" — уже некое состояние. Подразумевался request — response воркфлоу, вы это прекрасно поняли, не передёргивайте =)
Хотя согласен, сессия — вполне себе некое состояние, так же как и любая запись в хранилище (БД к примеру), привязанная к пользователю (читай — клиенту).
Про кеширование мы речь не ведем, если вы об этом.
А кеш тут причём? о_0 Я о нём даже не заикался, а опкеш — это стандартный механизм внутренней оптимизации кода в пыхе, начиная с версии 5.4 (да ведь?), в 7.2, по планам, будет заменён (ну или дополнен) на JIT.
И на счёт вымышленности плюсов… Я понял, что вас не переспорить, т.к. просто мало (нет) опыта работы с пыхом, против, например джавы или хакса (соль-перец по вкусу).
Fesor
05.07.2016 00:36+2И за каким состоянием в ноде надо следить за которым в пхп не надо?
- соединение с базой данных — состояние, нам уже нужно держать пул соединений и самостоятельно все разруливать
- stateful сервисы (аунтентификация, сессии) — тут опять же нам нужно держать пул таких сервисов и отчищать после ответа или инициалировать их по новой на каждый запрос.
- переменные хранящие состояние и объявленные вне скоупа обработчика запросов. Ну мол типа глобальные в этом контексте.
А еще весело заниматься отладкой проблем возникающих только при конкурентных запросах.
Очень многие начинающие разработчики на node.js которые пришли скажем из фронтэнд комьюнити слишком привыкли к тому что stateful не вызывает проблем, и в итоге на сервере потом возникают весьма причудливые баги как только начинают приходить конкурентные запросы. (ну и тестят они в одиночку, а стало быть и проблем воспроизвести не могут).
Все то что я перечислил — это все легко и просто обходится. Полно готовых решений которые скрывают эти нюансы и ограничивают возможности разработчика в том что они могут делать. Так же если знать о проблемах то допускать такие ошибки вряд-ли будут.
то есть в этом плане PHP который подчищает за разработчиком после каждого запроса — это несомненно жирный плюс PHP и как по мне тот самый "понижатель пороха вхождения". Можно писать сколь угодно плохой код и он будет работать (до поры до времени). С другой стороны многие PHP разработчики уже перешли от умирающей модели выполнения к более-менее конкурентной на базе reactphp и похожих фреймворков. Конечно до производительности ноды там далеко, но разрыв значительно сокращается.
Ну и потом, в силу "синхронности" мы можем просто увеличить количество воркеров. Да, будет огромный оверхэд особенно в плане времени переключения контекста между процессами, но все же… дешево и сердито. И разработчики дешевые настолько что можно пару лишних серваков докупить на всякий случай. Ибо с дешевыми node.js разработчиками вероятность получить неподдерживаемое ведро макарон намного выше.
YemSalat
05.07.2016 15:34соединение с базой данных — состояние, нам уже нужно держать пул соединений и самостоятельно все разруливать
Почему самостоятельно? Для этого всего используются библиотеки. То что в 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 сводятся к тому что на нем много дешевых и неопытных разработчиков?
Это факт, но речь же была не об этом…
Sannis
05.07.2016 22:18+1Зачем очищать или инициализировать по новой?
Каких проблем конкурентных запросов? Node однопоточна, что избавляет от проблем конкурентного доступа к данным на корню.
Вы серьёзно сейчас пытаетесь сравнивать один однопоточный сервер Node и один php-fpm с одноим воркером? Как только вы начинаете запускать Node cluster или несколько процессов на одном сервере или выходите за рамки одного сервера приходится заниматься всем этим, какую бы видимую простоту Node вам не сулила.
Fesor
06.07.2016 01:14Чем готовые решения ограничивают возможности?
я говоню о этих ограничениях в положительном ключе. Это хорошие ограничения.
OpieOP
28.06.2016 11:28Go автоматом создает новые процессы для потоков (горутин), если сочтет нужным. В node.js можно перекинуть отдельное действие только на другой процесс. На сколько одно эффективнее другого — без понятия.
lucky_libora
27.06.2016 22:58+3никто не запрещает замутить кластер с нодой, тогда будет сколько вам угодно потоков
если, к примеру, использовать кластер для http-сервера, то запросы будут распределяться между потоками по алгоритму Round RobinIvanPanfilov
29.06.2016 14:47замутить можно что угодно. вопрос в целесообразности.
— в PHP это уже есть, сложившаяся годами архитектура на воркерах веб сервера со времен зарождения PHP
— в go такие костыли просто не нужныmaxru
30.06.2016 18:38в PHP это уже есть, сложившаяся годами архитектура на воркерах веб сервера со времен зарождения PHP
Ну так уж и годами. С 5.3.3 только в стандартной поставке.
fornit1917
30.06.2016 18:58А причем тут 5.3.3 (с момента выхода которого, кстати, прошло 6 лет уже)?
А mod_php, которому уж точно сто лет в обед, на таком же принципе работает. Так что да, годами.Fesor
30.06.2016 20:07mod_php работает на простом принципе. Берем HTTP запрос и дергаем PHP скрипт. никаких воркеров.
Воркеры это часть архитектуры апача. И между прочим в Go примерно то же самое выходит если мы хотим организовать горячую подмену кода.
fornit1917
01.07.2016 09:53Верно, но это не отменяет того факта, что работа на процессах-воркерах это уже очень давно сложившийся принцип у PHP. Я только лишь это и имел в виду.
Fesor
01.07.2016 10:07В go что-ли не так? Ну хорошо, распределением по "воркерам" занимается сам рантайм языка. Это координально что-то меняет?
К примеру для PHP есть еще такой "кастыль": https://github.com/php-pm/php-pm
fornit1917
01.07.2016 10:20Про go я вообще ничего не говорил). Мое сообщение было всего лишь небольшим замечанием к
этому комментарию
Fesor
30.06.2016 20:09+2в go такие костыли просто не нужны
как вы организовываете zero-downtime деплоймент с go, коль кастыли эти в виде отдельных процессов воркеров не нужны? Придерживаете коней (у нас же полностью ресурсы машины утилизируются, так?), поднимаете новую версию апы, тушите старую и отпускаете коней?
То есть как с кастылями на воркерах на горячую подменять не выйдет?
caballero
28.06.2016 10:24+2Высокая скорость обработки запроса скорее всего упрется в относительно низкую скорость HTTP. И, если скорость работы сервака можно тупо увеличить более мощным железом, которое нынче копейки стоит, то скорость передачи от нас мало зависит.
Что касается асинхронки. Польза очевидна если надо отправить почту или записать лог. Но в большинстве случаев программа должна дождаться окончания операции и вернуть результат иначе данные могут потерять консистентность. С этой точки зрения операция синхронна и то, что длительную операцию выполняет другой поток или event сути дела не меняет
Преимущество ноды в основном если надо отправить много мелких ответов, например месажи в соцсетях — создавать каждый раз контекст страницы как в PHP для отправки пары килобайт действительно громоздко. Но таких сайтов — подавляющее меньшинство.
ИМХО — преимущества ноды сомнительны а трудоемкость разработки очевидно выше (напомню что труд програмиста нынче гораздо дороже железа). Попросту говоря нода предназначена для работы в определенной узкой нише не более того.
.YemSalat
28.06.2016 12:01+1то, что длительную операцию выполняет другой поток или event сути дела не меняет
как это не меняет? Если в этот же процесс придет еще один запрос, то в пхп ему придется ждать пока выполнится первый, до того как он вообще может что-то отправить обратно.
для отправки пары килобайт действительно громоздко. Но таких сайтов — подавляющее меньшинство.
кхм, а большинство REST апи — разве не именно это? Oтправляют всего по несколько килобайт на каждый запрос, и часто вообще ничего кроме заголовков не отправляют.
ИМХО — преимущества ноды сомнительны а трудоемкость разработки очевидно выше (напомню что труд програмиста нынче гораздо дороже железа)
очень спорное утверждение, почему на ноде сложность «очевидно» выше? В чем именно выражаются трудности?caballero
28.06.2016 12:46-1Если в этот же процесс придет еще один запрос
то что нода пихает новый запрос в тот же процесс — проблема ее архитектуры. Точнее особенность архитектуры полезная для отправки много мелких сообщений.
Не надо использовать ноду куда она не подходит.
а большинство REST апи — разве не именно это?
подавляющему большинству сайтов не нужно никакое апи. Кроме того апи не означает что там обязательно мелкие данные. Там и гигабайты могут передаватся зависит от прикладной задачи
очень спорное утверждение, почему на ноде сложность «очевидно» выше
сравните с PHP который в отличие от яваскрипта изначально заточен на серверную обработку.
Fesor
28.06.2016 14:30+1Там и гигабайты могут передаватся зависит от прикладной задачи
Сейчас тренды — мобильные приложения. Даже если вы пишите API не для мобилок, добрая половина трафика сейчас с мобилок. А стало быть подавляющее большинство старается уложиться в желаемые 50Кб на респонс.
сравните с PHP который в отличие от яваскрипта изначально заточен на серверную обработку.
javascript изначально заточен под I/O bound задачи, а для web это 90% всех задач. PHP же заточен под сайтики, он stateless и т.д. 10 лет назад у него небыло конкурентов, сегодня "изоляции" можно добиться другими способами. Но соглашусь что уровень разработчика в среднем для ноды должен быть выше.
Техническая возможность причем сделать все что угодно есть и у одного и у другого языка.
p.s. работаю и с похапэ (основной язык) и с нодой.
YemSalat
29.06.2016 09:39+1то что нода пихает новый запрос в тот же процесс — проблема ее архитектуры. Точнее особенность архитектуры полезная для отправки много мелких сообщений.
Не надо использовать ноду куда она не подходит.
Почему эта архитектура, по-вашему, не подходит для отправки много больших сообщений?
подавляющему большинству сайтов не нужно никакое апи. Кроме того апи не означает что там обязательно мелкие данные. Там и гигабайты могут передаваться зависит от прикладной задачи
«подавляющему большинству небольших сайтов не нужно никакое апи» — так правильнее.
На дворе 2016 год, большинство современных веб проектов движутся в сторону одностраничных приложений.
Т.е. гонять по сети мегабайты ХТМЛ — это не нормальная ситуация для текущих тенденций в разработке.
Если брать абсолютные цифры — то большинство сайтов это обычные блоги на вордпрессе и т.п. где «работой программиста» вообще не пахнет.
Но мы же с вами про профессиональную разработку говорим?
сравните с PHP который в отличие от яваскрипта изначально заточен на серверную обработку.
Мы вроде сравниваем node с php как платформы, а не как языки программирования.
node тоже изначально заточена на серверную разработку, разве не так?caballero
29.06.2016 11:27Почему эта архитектура, по-вашему, не подходит для отправки много больших сообщений?
потому что в этом случае нет никаких преимуществ перед более простым для разработки PHP
На дворе 2016 год, большинство современных веб проектов движутся в сторону одностраничных приложений.
Это даже близко не так. Да, есть мода на SPA. Но SPA не дает никаких преимуществ для пользователя — ему пофиг как там сделано. Но SPA однозначно более трудоемкие в разработке. Уж поверьте — как раз приходится сопровождать после любителей модных фишек проект сделаный на Flex.
Т.е. гонять по сети мегабайты ХТМЛ — это не нормальная ситуация для текущих тенденций в разработке.
текущие тенденции — это тестирование сетей 5G. Повышать стоимость разработки экономя на трафике и перегружая мобильные браузеры яваскриптовыми фреймворками — уж точно ненормально. Да и нет в нормально сделанном сайте (flat desidn и google style рулят) мегабайтов HTML.
node тоже изначально заточена на серверную разработку, разве не так?
Нода изначально заточена на обработку множества мелких сообщений которые обрабатываются в одном потоке. В этом и был смысл. Все остальное — от лукавого.
Это типа как вордпрес, который изначально заточен на блоги но фанаты умудряются делать на нем интернет-магазины.
YemSalat
29.06.2016 12:26+1потому что в этом случае нет никаких преимуществ перед более простым для разработки PHP
Преимущество node — скорость. И пожалуйста, объясните чем PHP «проще» для разработки?
Еще раз повторю, что мы говорим про простоту в использовании для профессионального разработчика, а не для любителя.
(Например, в PHP «нативно» поддерживается работа с MySQL, но зато нету пакетного мэнеджера из коробки и нужны «дополнительные заморочки» если требуется работа с сокетами, и т.д..)
Это даже близко не так. Да, есть мода на SPA. Но SPA не дает никаких преимуществ для пользователя — ему пофиг как там сделано. Но SPA однозначно более трудоемкие в разработке. Уж поверьте — как раз приходится сопровождать после любителей модных фишек проект сделаный на Flex.
Простите, но «на слово» не поверю, приводите аргументы. Сам сопровождал как «традиционные» проекты, так и SPA — не могу сказать что трудозатраты сильно отличаются.
С Flex'ом никогда не работал, и это скорее исключение, абсолютное большинство веб приложений пишется на HTML5
Преимущество для пользователя, опять же — скорость. При первоначальной загрузке отдаем только статику, затем по мере надобности подгружаем данные. Никаких перезагрузок страниц и т.д.
текущие тенденции — это тестирование сетей 5G.
Точно, скажите это подальше от центра.
И исходящий от сервера трафик тоже никто не считает…
Повышать стоимость разработки экономя на трафике и перегружая мобильные браузеры яваскриптовыми фреймворками — уж точно ненормально.
А жрать деньги клиента на трафике — это нормально?
Я понимаю, что вам возможно в плане бизнеса пофиг на то, сколько данных туда-сюда ходит, но поверьте это точно не повод для гордости в современной веб-разработке.
Нода изначально заточена на обработку множества мелких сообщений которые обрабатываются в одном потоке.
А веб-сервер — это разве не обработка множества мелких сообщений от клиентов??
Это типа как вордпрес, который изначально заточен на блоги но фанаты умудряются делать на нем интернет-магазины.
Это нифига не как «вордпрес», node отлично подходит для огромного количества типов проектов, в том числе для магазинов и т.п.
em92
29.06.2016 12:35+1SPA не дает никаких преимуществ для пользователя — ему пофиг как там сделано.
Для пользователей мобильного интернета важно. Ему бы хотелось экономить трафик.
SPA однозначно более трудоемкие в разработке.
Спорное утверждение. Сохранение состояния отдельных html-элементов легче решать в SPA приложении, чем в «не-SPA». Бэкенд тут уже можно выбирать на свое усмотрение. Хоть на php.caballero
29.06.2016 13:06-1Преимущество node — скорость.
при использовании ноды в той нише для которой она предназначена.
Еще раз повторю, что мы говорим про простоту в использовании для профессионального разработчика, а не для любителя.
не помню что бы мы вообще упоминали какой разработчик. Не надо подтасовывать дискусию под свои аргументы. Порог вхождения в PHP однозначно ниже.
в PHP «нативно» поддерживается работа с MySQL,
в PHP нативно поддерживается 99% процентов того для чего в ноде нужен пакетный менеджер.
нету пакетного мэнеджера из коробки
Composer вполне справляется.
А веб-сервер — это разве не обработка множества мелких сообщений от клиентов??
по моему вы смутно понимаете изначальный смысл ноды и ее отличие от других вебсервероо.
Для пользователей мобильного интернета важно. Ему бы хотелось экономить трафик.
Гораздо более ему бы хотелось чтобы страницы не тупили за каждым телодвижением изза клиентского яваскрипта.
А трафик на мобиле в основном жрет медиаконтент а не HTML. Не говоря уже про приложения на андроиде постоянно лазающие в инет.
Сохранение состояния отдельных html-элементов легче решать в SPA приложении, чем в «не-SPA»
Если использовать вменяемый бекенд а не MVC то никаких проблем с сохранением состояния нет. Лично у меня точно — для того и написал свой фреймворк.
YemSalat
29.06.2016 16:25+1по моему вы смутно понимаете изначальный смысл ноды и ее отличие от других вебсервероо.
Нет, по-моему это вы не понимаете, что за 7 лет с тех пор как вышла node в веб-разработке многое изменилось и она применяется для гораздо более широкого круга задач чем просто «чатики»
не помню что бы мы вообще упоминали какой разработчик. Не надо подтасовывать дискусию под свои аргументы.
Я ничего не подтасовываю, зачем вообще обсуждать разработчиков, которые не осилили порог вхождения?
Если вы набираете вчерашних студентов или дешевых фрилансеров — согласен — PHP ваш лучший выбор, но более продвинутых разработчиков, на мой взгляд, не должен останавливать порог вхождения.
в PHP нативно поддерживается 99% процентов того для чего в ноде нужен пакетный менеджер.
Ага, и постоянно таскается за собой в виде миллиона хаотично названных функций в глобальном пространстве имен.
(А еще там только только появилась нормальная поддержка Юникода)
Кроме того, некоторые вещи, которые в node есть из коробки (сокеты и т.п.) в PHP требуют танцев.
Гораздо более ему бы хотелось чтобы страницы не тупили за каждым телодвижением изза клиентского яваскрипта.
Покажите мне «тупящее» одностраничное приложение, и схожее по функционалу, не «тупящее» классическое.fornit1917
29.06.2016 16:39Ага, и постоянно таскается за собой в виде миллиона хаотично названных функций в глобальном пространстве имен
Это хоть как-то мешает?
(А еще там только только появилась нормальная поддержка Юникода)
Ээээ… это какая такая «нормальная поддержка Юникода» появилась в PHP «только только», не подскажите? Поддержки юникода в ядре PHP нет, не было и, похоже, не будет. Все задачи, связанные с юникодом, прекрасно решаются расширениями уже давным-давно.
YemSalat
01.07.2016 08:11+1Это хоть как-то мешает?
Конечно, делает работу с языком менее удобной.
Если какая-то функция станет не актуальной (например как mysql_*) — вам придется переписывать приложение, вместо того чтобы просто обновить библиотеку.
Вообще в подходе «весь функционал языка в виде миллиона глобальных функций» я вижу только минусы.
Плюс от экономии времени (мол, не нужно никаких библиотек подключать, просто фигачишь прямо на языке) — для меня лично сомнителен, больше похоже на «медвежью услугу».
Насчет юникода — прошу прощения, ошибся, действительно в седьмой версии он до сих пор не поддерживается полностью.
В чем заморочки? В том, что например, в той же node — мне вообще никогда не нужно думать об этом. Все строки по умолчанию UTF8 с полной поддержкой юникода. String.length никогда не вернет мне неверную длину.
YemSalat
29.06.2016 16:47+2А трафик на мобиле в основном жрет медиаконтент а не HTML.
А вот это как раз сильно зависит от приложения.
Например, если посмотреть эту страницу (а хабр не является одностраничным приложением), то видно что большая часть трафика — это как раз JS/HTML/CSS
(кликабельно)
И есть еще куча ресурсов где медиа контент не является основным.
31415
28.06.2016 11:28+1В чём причина отставания V8 от Oracle Java в скорости работы вычислительных алгоритмов, например, числодробилок (т.е. когда GC не вмешивается)?
Эта причина временная или фундаментальная? Связано ли она с типизацией языков?
При первом приближении (если не брать во внимание то, что у V8 вообще нет интерпретатора) обе реализации работают примерно одинаково — ищут «горячие» участки кода и более тщательно оптимизируют их. Почему тогда несмотря на «миллионы гугла» за много лет оптимизатор V8 так и не приблизился к HotSpot? Понятно, что HotSpot это вроде как state of art, но именно V8 (иногда вместе с LuaJIT) хоть как-то могут противопоставить свой JIT продукту Oracle.
Хотелось бы, конечно, узнать ответ от mraleph, но любой приму с благодарностью.Fesor
28.06.2016 12:30+2В чём причина отставания V8 от Oracle Java в скорости работы вычислительных алгоритмов, например, числодробилок
Динамические языки оптимизировать очень сложно. В Java вся необходимая информация для оптимизаций доступна на этапе компиляции, в JS же компиляция происходит по сути в рантайме. оптимизирующий компилятор входит в бой только для горячего кода, который выполняется очень часто (так как оптимизация и анализ кода весьма дорогая операция насколько я понимаю).
Так же насколько я помню JVM умеет такие маленькие радости как автоматическая векторизация вычислений, чего в ноде пока нет, хоть и есть проекты вроде simd.js.
В целом же есть еще такие штуки как asm.js или webassembly которые могут быть аналогом JNI для java.31415
28.06.2016 17:39Какая именно информация есть у HotSpot, но нет у V8?
А если использовать TypeScript — у не го вроде типы можно декларировать?
JNI вообще не о том.Fesor
28.06.2016 18:38+1Какая именно информация есть у HotSpot, но нет у V8?
информация о типах и структурах данных. В силу того что javascript динамический язык (то есть мы можем любую структуру менять в рантайме) оптимизирующий компилятор должен это учитывать. Поменялись структуры — нужно перегенерить код. Если структуры не меняются, если все относительно статично — то V8 будет генерировать очень эффективный код.
Если хотите, можете послушать неплохую лекцию на тему того как работает JIT в V8: https://www.youtube.com/watch?v=Z_q6iw3h48s
А если использовать TypeScript — у не го вроде типы можно декларировать?
Информацию о типах TypeScript использует исключительно в целях статического анализа, на рантайм это никак не влияет. С другой стороны это ограничивает разработчика в том какой трэш он может творить и по идее мы придем к относительно стабильным структурам данных и V8 опять же сможет это все красиво оптимизировать.
JNI вообще не о том.
JNI о том, зачем извращаться если можно реализовать какой-то критичный алгоритм на Сях и получить сразу эффективный код?
Amareis
28.06.2016 13:58Потому что динамические языки оптимизировать куда сложнее, а ещё потому что миллионы долларов, вбуханные ораклом в хотспот ;)
Deosis
28.06.2016 11:29+1Offtop: «Cranshaft состоит из двух компонентов: Hydrogen и Lithium.» Куда дели Helium?
uniqm
28.06.2016 12:38+1На многих языках есть реализация EventLoop-а: Ruby и EventMachine, C и Nginx, Pyton и Tornado, JavaScript и Nodejs, и тд. И у всех одна ниша применимости (как выше и писали): много i/o запросов, упирающихся в ожидание ответа сети/диска/сервиса, а не в процессор. С девизом «Никогда не останавливаем(не блокируем) цикл».
Ну и нода не самая быстрая реализация этого подхода. Хотя кому по душе JavaScript, то пойдёт.
bo883
28.06.2016 23:20Писал я парсер сначала на php, потом переписал на nodejs. Парсер должен был скачивать/обрабатывать более 30к записей. С php намучился(потреблял дикое кол-во памяти, падал и обрабатывала за раз меньшее кол-во записей), нода приятно улыбнула(время работы 1-1.2час).
Fesor
29.06.2016 00:52+1Было бы намного интереснее сравнить вашу реализацию на PHP и на Node. Ибо я могу себе представить реализацию на PHP которая работает не сильно хуже и не сильно медленнее, ну и опять же могу представить себе ужасную синхронную лапшу.
bo883
29.06.2016 09:46Увы я не могу показать код, жаль. Но могу сказать — php реализация асинхронна.
symbix
29.06.2016 19:10Асинхронно тоже можно сделать по разному. Между, скажем, select() и epoll() разница в производительности может быть очень сильно заметна.
Я сравнивал производительность node.js и reactphp+ext/event — reactphp получился медленнее в полтора раза, причем это был совершенно искусственный тест типа «отдать hello world», и это был php 5.6. На реальных задачах разница будет меньше.
lucky_libora
29.06.2016 19:25+2писал парсеры на .net, java, scala и на ноде
как по мне так нода самый удобный вариант из перечисленного, особенно с модулем jsdom. Все сводится к тому что просто пишешь и отлаживаешь js-код в консоли браузера, который достает нужные данные, и копипастишь его в нодовский файл
стоит также отметить, что с использованием Promise код становится весьма компактным и читабельнымgearbox
29.06.2016 21:17+1стоит также отметить, что с использованием Promise код становится весьма компактным и читабельным
Добавлю также что на ноду можно и нужно писать на typescript, но даже если нет — async/await и бабель, но хейтеров это не остановит — они будут продолжать пинать яваскрипт нулевых годов также как хейтеры пыха пинают четвертый пых, не обращая внимания на реалии.
Fesor
NodeJS тоже. просто есть из коробки неблокируемое API. А так все вполне синхронно. В PHP проблема что асинхронщины из коробки нет, есть возможность делать корутины. Ну и в целом ситуация по PHP примерно такая: https://github.com/elazar/asynchronous-php
Опять же, это не ограничение платформы, это дефакто стандарт. Но никто вам не мешает взять reactphp и вперед. Другой вопрос что рациональность этого под вопросом так как "умирание" PHP его основной плюс.
5 воркеров обрабатывающих один запрос на PHP памяти жрут всеравно чуть меньше чем nodejs. Ну а так как в штуках типа php-fpm 5 воркеров это максимум (настройки по умолчанию если брать) то как бы все хорошо.
Мне тут на днях понадобилась простенькая тула, и так как я не хотел ее писать, взял готовое под nodejs. Но вот проблема, операция над одним файлом занимала 0.01 секунду (и на php было бы так же), а холодный старт порядка секунды. И автор тулзы не дал возможности делать пакетную обработку.
Так что все относительно.
eyeofhell
Ради обсуждения на Хабре и публикуется. ReactPHP пробовали? Как оно в продакшн?
symbix
Нормально в продакшене. Есть специализированный чатик, уже скоро год как стабильно работает, утечек памяти нет, перезапускаю только при обновлении софта.
Fedot
У нас на reactphp крутиться вся работа с очередями, вэб сокетами, таймерами и т.д.
Работает отлично.
tatu
Довольны, используем уже больше года на нескольких проектах
sky2high0
Асинхронность в php — это не стандарт разработки, в отличие от node.js, где неблокирующее API — стандарт, который в первую очередь описывается во всех мануалах.
node.js хорош именно тем, что «направляет» писать довольно быстрые приложения.
Fesor
Скорее не мэйнстрим. А техническая возможность имеется уже очень давно.
sky2high0
Это и имелось в виду. Эта возможность не ставится на первый план.