Как работает SSR-Rendering в NODEJS и почему он отличается от PHP?
Добрый день.
Перевел проект с PHP на Nuxt ssr, производительность сильно просела, судя по ab тестам.
Добрые люди сказали, что nuxt (node) рендерит контент на сервере не также, как это делает PHP и проигрышь в производительности очевиден и оправдан. В nodejs для рендеринга работает рендер-функция и вообще эта технология гораздо сложнее, а поэтому медленнее.
Я всегда думал что работает это так:
- PHP принимает запрос, выполняет скрипт, "собирает" разметку и отдает браузеру.
- Nodejs всё делает примерно также. В случае с современными JS фреймворками (react, vue) выбор nodejs для серверного рендеринга обусловлен тем, что бОльшая часть кода на JavaScript будет выполняться на сервере, а код который не может быть выполнен на сервере (DOM, Window, XHR etc) должнен быть обработан в завимисости от того, где он запущен.
Ну то есть вместо nodejs можно было бы и PHP использовать для серверного рендеринга и тогда не было бы никакой разницы между серверным рендерингом и обычной (по старинке) генерации ответа на сервере, когда переход по страницам - это всегда новый запрос на сервер.
Объясните, пожалуйста, в чем разница между рендерингом на PHP и на Nodejs и почему второй гораздо менее производительый?
SSR-это запуск фронтендового js-фреймворка на ноде заранее,(вместо работы в браузере) и отдача клиенту того что получилось, вместе с фреймворком, дальше все это продолжает работать на клиенте.
на php этого просто нет.
почему второй гораздо менее производительый?
правильно вопрос звучит так "почему то что у меня на nodejs написано медленнее того что у меня было на php" ответ как вы понимаете зависит от того что именно у вас там написано. В целом рендеринг на ноде не медленнее рендеринга в php сам по себе. Может у вас так все настроено, может как раз ssr тормозит
SSR-это запуск фронтендового js-фреймворка на ноде заранее,(вместо работы в браузере) и отдача клиенту того что получилось, вместе с фреймворком, дальше все это продолжает работать на клиенте.
на php этого просто нет.
Давайте разберем: Запуск фреймворка на сервере. - Ну запуск и запуск, PHP тоже на сервере запускает php-framework. дальше все это продолжает работать на клиенте - ну то что это продолжает работать на клиенте ведь никакой нагрузки на сервер не создает. Сервер отдал разметку и все отдача клиенту того что получилось, вместе с фреймворком - вот тут единственная разница с PHP. PHP просто отдает разметку, а тут еще и весь код. Это увеличивает размер данных, но существенно влиять на должно.
Я пытаюсь понять разницу между PHP и серверным рендерингом на Node. Вот из вашего ответа разница только в объеме ответа сервера.
Еще раз, имеется в виду запуск фронтенд-фреймворка на сервере, который и выступает в качестве шаблонизатора. Естественно, так как фронт-фреймворк гораздо больше по функциональности, чем шаблонизатор, это будет работать дольше.
Т.е. если вы начнёте рендерить не Vue приложение, а просто какой-нибудь pug шаблон -- будет в разы быстрее
WebDev, вы занимаетесь буквоедством вместо того чтобы посмотреть что происходит.
Запуск фреймворка на сервере. - Ну запуск и запуск, PHP тоже на сервере запускает php-framework.
Совпадают только слова запуск и фреймворк. На байконуре тоже чего-то запускают. Реально происходящие процессы разные настолько что их сравнивать можно только с очень большой натяжкой и в сферическом вакууме.
Robur, Вот как я проверяю:
Взял страницу about с текущего проекта. Там только текст и картинки. Никакой логики нет, никаких обращений на сервер нет.
Положил эту страницу в /pages на nuxt, собрал, запустил через pm2 cluster mode и запустил нагрузочный тест ab -n 1000 -c 100. Результат ~ 200 запросов в секунду.
Теперь я беру эту же страницу, создаю роут в laravel и по адресу /about отдаю ее. Тест ab -n 1000 -c 100 выдает уже ~940 запросов в секунду.
Я, к сожалению, не могу перенести что-то более сложное с nuxt на php, потому что на это нужно время.
Я не могу сравнить и оценить работу рендера nuxt, у меня недостаточный уровень знаний, чтоб открыть исходный код и разобраться в нем, я поверхностно знаком с nodejs.
Поэтому я и обращаюсь сюда с вопросом: почему рендеринг обычной текстовой страницы на php в 4-5 раз быстрее, чем на nuxt? Ну или по-другому: "Действительно ли рендеринг обычной страницы на php в 4-5 раз быстрее, чем на nuxt"? Потому что мне в первую очередь важно понять не почему так, а действительно ли так, потому что у меня подозрения, что это я что-то не так сделал.
Вместо ответа мне предлагают посмотреть на код рендера, использовать кэширование и еще кучу всего.
И ваш ответ я тоже не понимаю. Вы говорите:
SSR-это запуск фронтендового js-фреймворка на ноде заранее,(вместо работы в браузере) и отдача клиенту того что получилось, вместе с фреймворком, дальше все это продолжает работать на клиенте.
на php этого просто нет.
Фреймворк - это что? Обработка роутинга, затем запуск кода, выполнение кода, получение каких-то результатов и отдача получившегося клиенту.
Чем запуск js фреймворка на сервере отличается от запуска php фреймворка на сервере? У js фреймворков код хуже написан или nodejs медленнее, чем php?
Действительно ли рендеринг обычной страницы на php в 4-5 раз быстрее, чем на nuxt"
ответ простой - да. Не знаю насчет 4-5 раз но - да.
А еще быстрее он будет если это будет просто html. А еще быстрее - если отдавать хорошо настроенным nginx. А еще быстрее - если правильно сделать кеширование. А еще быстрее - если положить на CDN.
Только вопрос - зачем вам рендерить обычную страницу с текстом на nuxt? Если у вас такие задачи - он вам не нужен и брать его будет неправильно. Инструмент не для этого.
Чем запуск js фреймворка на сервере отличается от запуска php фреймворка на сервере? У js фреймворков код хуже написан или nodejs медленнее, чем php?
Тем что это совершенно разные вещи и делают они разное.
Если уровень вашего интереса и желания разобраться достигает только ситуации "мне надо отдать html и больше ничего" - то берите php, отдавайте свой html и будьте счастливы
Robur, глупо было бы месяц переписывать приложение, чтобы лишь потом узнать, что оно стало работать в 5 раз медленнее. Так что автор прав в том, что начал с тестов.
Конечно, большой вопрос правильно ли он тестирует. WebDev, попробуйте потестировать утилитой wrk - она работает в несколько потоков и её результат будет ближе к реальности.
Антон Спирин, Автор по видимому просто не хочет вникнуть что это такое и как оно работает.
"что-то одно делает мне html на сервере, и вот что-то другое тоже мне делает html, ну нет же разницы"
Антон Спирин, сравнивать инструменты выполняющие одну и ту же задачу корректно. То, что один из них делает намного больше работы и разница в скорости критична - ну что ж, значит медленный не пригоден для решения конкретной задачи.
batyrmastyr, в случае автора правильней сравнивать производительность конкретного PHP фреймворка и Nuxt, а не PHP и Node.js, Автору бы разобраться с инструментами которые он использует, но видимо это не его стиль. Судя по его комментариям он даже не понимает зачем притащил в свой проект nuxt и какие преимущества дает это решение.
Антон Спирин,
Я сравниваю производительность конкретного PHP фреймворка (Laravel) и Nuxt.
Голый PHP будет еще быстрее, потому что не будет накладных расходов на фреймворк.
Для упрощения я свел вопрос к PHP и Node, потому что в конечном счете все сводится к их работе. Будь на месте Laravel Yii или Symfony, ситуация кординально не изменится.
Проект я перевел на nuxt, чтобы получить преимущества vuejs на клиенте и сохранить возможность сео-продвижения.
Поэтому сравнение альтернативных технологий имеет место быть, перевод проекта на nuxt сделан осознанно, но, к сожалению, Nuxt действительно гораздо медленнее рендерит страницы, если сравнивать с Laravel.
А вот зачем писать бессмысленные комментарии и пытаться оскорблять , я не понимаю. "Видимо это не его стиль", "Судя по его комментариям" и тд. Вас никто не просит читать мои комментарии и делать какие-то выводы. Я задал вопрос. Если вам этот вопрос не нравится - пройдите мимо.
На Тостере очень много токсичных людей, которые, видимо, заходят сюда самоутвеждаться. Или у них просто других дел нет. Вы видимо один из таких.
