Выигрывает ли nodejs в производительности php на примере обычного сайта?

Question

[devilsD]

Известно что скорость обработки nodejs сопоставима с компилируемыми ЯП. PHP в таких тестах проигрывает в сухую как и любой интерпретируемый язык.
Но как ведет себя nodejs на обычном монолитном сайте, к примеру ИМ, с базой mysql/postgresql, веб сервером и другими плюшками стандартного веба в сравнении с php. Не учитывая настройки сервера, архитектуру и т.д. Вопрос стоит так: существенно ли будет отличаться время ответа сервера на nodejs сайте от сайта на php при одинаковых условиях.
Если брать в частности, ИМ на laravel/yii даже при использовании кэширования показывает задержку в 200-300ms.
Будут ли показатели отличаться при использовании nodejs?

Comments

[devilsD]

Bavashi, Есть линки?. т.к я предварительно погуглил, изучил несколько тестов, во всех nodejs на уровне с java и go

[devilsD]

Bavashi, Я имею ввиду в контексте асинхронности ноды. Если сравнивать тривиальные операции: работу с числами, строками и тд, то да php даже шустрее немного.

[Adamos]

devilsD, а вы всерьез готовы делать какие-то выводы из сравнения мощного универсального фреймворка на РНР с велосипедами на ноде? Имхо, тут только об организаторе сравнения можно достаточно уверенно сделать вывод.

[devilsD]

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

[Adamos]

devilsD,

фреймворк пыха как то выигрывает в производительности велосипеды на том же пыхе

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

Answer 1

[Дмитрий Беляев]

В общем случае все зависит от того как написать, можно и на ноде понаписать таких тормозов, что хорошо оптимизированный php, особенно 7, будет просто летать на фоне этого.
Ну и в большинстве серверных приложений основная нагрузка приходится на БД, а значит и скорость в большей части будет зависеть от нее.
Но за счет асинхронной работы нода однозначно выиграет у php по потребляемым ресурсам, что в конечном итоге так же может сказаться на производительности.

Comments

[devilsD]

ну да, тоже знаю и про асинхронность и супер движок V8. Но вот как это все на практике работает...

[Дмитрий Беляев]

devilsD, ну вот как пример, сисадмин с прошлой работы рассказывал:
был там написанный мной микросервис на ноде, работавший себе прекрасно в 4 процесса на ноде и обслуживавший примерно 15 тысяч запросов в секунду (не ахти какая нагрузка на самом деле)
и так как после моего ухода поддерживать все это было особо некому, а сервис был не особо большой, то переписали они его на php7, когда понадобился новый функционал.
Как итог пришлось все масштабировать под такой нагрузкой на 2 физические машины на 12 ядерных современных зионах.
Выводы делайте сами...

[Виталий]

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

[devilsD]

Виталий, Еще куда смотреть это разве что java из популярных. Но в Go смущает отсутствие как такового ООП, мне кажется не самое лучшее решение делать на нем монолитный сайт - ИМ или маркетплейс. Думаю он больше подходит для микросервисного подхода.
А по преимущества что фронт и бэк на одном и том же, думаю это субъективно. Нет особой проблемы сделать api на том же питоне, а фронт на реакте. Конечно если в арсенале знаний только нода, то это будет плюсом)

[Виталий]

devilsD, для примера лямода выбрала себе го для высоконагруженных проектов, ООП не ООП вопрос второй, если обсуждается вопрос экономии ресурсов и максимальной производительности, то нужно быть готовым идти на компромиссы. Я сравнивал ноду и го, производительность последнего была лучше, как бы я не мечтал об обратном. Разница была в 2 4 раза по числу ответов в секунду.

[Дмитрий Беляев]

devilsD, не одним ООП единым...
Виталий, дороговизна поддержки Go убивает все остальные его преимущества, тем более если уж речь заходит о быстродействии, то языки с GC всегда будут в проигрыше, если основной критерий - производительность непосредственно языка, выбор резко сокращается до C++, Rust и им подобных.
Ну и тот же Rust позволит сэкономить миллионы человекочасов по сравнению с Go, на поддержке кодовой базы, если смотреть в перспективе нескольких лет.

Я сравнивал ноду и го, производительность последнего была лучше

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

[Виталий]

Дмитрий Беляев, код тупой, круд, поход в базу за данными без лишних изысков, вот мне интересно как ты нодой го обогнал, можешь показать?

[Егор Казанцев]

вот не надо гнать на БД , в данном случае ИМХО жрет шаблонизатор .

Answer 2

[shsv382]

При выборе языка/фреймворка для бэкенда некорректно говорить о том, что один лучше, а другой хуже. Важна конечная цель. NodeJS может быть сколь угодно быстрее других при генерации простых веб-страничек, зато когда речь идет о работе с большими числами, то JavaScript проигрывает, потому что BigInt еще совсем сырой, а реализовывать вычисления со строками - такое себе развлечение. Я к тому, что выбор по одному критерию - не лучшая практика

Comments

[devilsD]

почему же по одному критерию. вопрос стоит о разработке сайта, к примеру ИМ - это совокупность критериев. Тут и работа с базой, и со строками и рендеринг страниц. Просто у меня нет опыта реальных проектов на node . Если б в данном конетксте меня попросили сравнить производительность php и python, я с ними работал и могу сделать некое заключение.

Answer 3

[Владимир Коротенко]

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

Comments

[Владимир Коротенко]

xmoonlight, Потому что 42. Невежливый и агрессивный собеседник. Если ты не пользовался профайлером то тебе минус, как эксперту всего на свете. В общем идите в.

[xmoonlight]

Владимир Коротенко, речь идёт о тебе! Ты пишешь:

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

Почему ты даёшь свою оценку, а не ответ на вопрос?!

[Владимир Коротенко]

xmoonlight, Потому что только профайлер даст ответ, а все остальное посылки к возможным вариантам.
Вот вам например сможет ответить только психолог, что у вас за комплексы. Сходите не так дорого

[xmoonlight]

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

[Владимир Коротенко]

xmoonlight, Ваши компетенции еще и постановка диагноза по аватарке? Вы великий человек и программист.

[xmoonlight]

Владимир Коротенко,

Ваши компетенции еще и постановка диагноза по аватарке? Вы великий человек и программист.

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

Answer 4

[xmoonlight]

Выигрывает ли nodejs в производительности php на примере обычного сайта?

конечно же это неверный вопрос. Всё зависит от реализации кода.
По тестам примитивных расчётов и операций: node.js значительно слабее php.

Если брать в частности, ИМ на laravel/yii даже при использовании кэширования показывает задержку в 200-300ms.

Сикоко-сикоко?!!!
Мой php-фреймворк на спичечном коробке это делает за 5-7ms максимум!
Поймите, что дело - не в языке и не во фреймворке, а в логике работы архитектурного алгоритма.

Заходите ко мне в блог - там я начал тему по архитектуре!

Comments

[xmoonlight]

Дмитрий, что не так? (многое непонятно?)

[devilsD]

Мой php-фреймворк на спичечном коробке это делает за 5-7ms максимум!
Поймите, что дело - не в языке и не во фреймворке, а в логике работы архитектурного алгоритма.

Где я писал что этого не понимаю. Одна из задача правильной архитектуры - структурировать приложение таким образом, чтоб код был расширяем и легко читаем и в целом оптимизировал процесс разработки. Конечно в результате построения абстракций, кушаются ресурсы. И вот тут и есть зависимость фреймворков от скорости, т.к один фреймворк более грамотно спроектирован, и менее прожорлив.
Но вернемся к вашему аргументу про 7мс. Есть у вас хоть один работающий пример на продакшне, с откликом в 7мс. Или дайте ссылку на репозиторий, я хотел бы протестировать ваше решение.

[xmoonlight]

devilsD,

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

чтобы избавиться от абстракций и переменных.
В моём блоге - пример кода подсчёта сумм. Берите и изучайте.
(возможно, что данный метод для Вас нов, необычен и будет непонятен некоторое время, но со временем Вы осознаете: почему сделано именно так и как его масштабировать под любые задачи)

Но вернемся к вашему аргументу про 7мс. Есть у вас хоть один работающий пример на продакшне, с откликом в 7мс.

Я бы иначе не писал об этом. Могу сделать демку под Ваш запрос, если хотите убедиться в силе моих слов.

[devilsD]

xmoonlight, я надеюсь вы прикалываетесь, когда говорите о 5ти строках кода как об архитектуре и масштабировании. Такому только учить на школьных уроках информатики...

[xmoonlight]

devilsD, нет, не прикалываюсь. Это просто самый минимальный пример, который возможен.
Я постепенно буду расширять его до размера простого блога (комментируя код по-строчно), чтобы показать принцип применения такой архитектуры и все "плюсы" и "минусы".
Пока - постарайтесь понять: почему код содержит всего одну входную переменную (она так и останется одной при любой сложности задачи проекта).

Answer 5

[Павел]

https://thinkmobiles.com/blog/php-vs-nodejs/ вот вам сравнение, не стоит думать, что php сильно проигрывает.

Comments

[devilsD]

Павел, По тестам он не проигрывает) . Встречал где-то перевод этой статьи.
Но статья не совсем даёт ответ на мой вопрос. В тестах не учитывается взаимодействие с бд

[Павел]

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