LINUX.ORG.RU

ngnix vs nodejs

 , ,


0

2

Вот вроде рекомендуют ставить перед любым вебсервером ngnix, для статики. В принципе, nodejs тоже асинхронный, и я не вижу смысла ставить ngnix, перед ним. Нафига? Mожно им же и отдавать статику.

По моему скромному опыту, проблем с этим nodejs не имеет. Действительно ли ngnix,имеет тут серьезные преимущества? Чем он лучше? Он что, с диска лучше читает, или что?



Последнее исправление: onceagain2017 (всего исправлений: 1)

А ты кто, дев, опс?

stave ★★★★★
()

Если на непрогретый кластер из сервисов nodejs накинуть 5млн хитов то он упадет, а вот если поставить перед ним nginx и сделать на основе nginx лимиттер, то nginx выживет. Дальше обсуждать что-либо бесполезно.

Deleted
()
Ответ на: комментарий от onceagain2017

Можно раскидать эту нагрузку по разным машинам

Разница в затратах между Nginx и несколькими машинами настолько неочевидна?

WereFox ★☆
()
Ответ на: комментарий от WereFox

Всему есть предел, масштабирвание все равно лучше скорости. Но я не о том. Я говорю, засчет каких внутренних своих характеристик он обходит nodejs? Там же то же самое чтение с диска, к этому все сводится

onceagain2017
() автор топика
Ответ на: комментарий от onceagain2017

nginx нормально масштабируется, nginx имеет более адекватный объем потребляемой памяти, nginx заточен на выполнение одной простой вещи и делает это хорошо. У тебя уэбмакаки в той-же ноде начнут бизнеслогику фигачить, свои server-side rendering`и делать и всячески мешать раздаче статики.

Deleted
()

Он что, с диска лучше читает, или что?

Он не использует тормозную libuv и поэтому быстрее ~20-30%. Если ты думаешь, что это мало, то вспомни, что это на 1 ядро.

no-such-file ★★★★★
()
Ответ на: комментарий от onceagain2017

засчет каких внутренних своих характеристик он обходит nodejs?

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

waker ★★★★★
()
Ответ на: комментарий от Deleted

Вот да, ты это несколько сумбурно описал, но примерно прав.

Бизнес-логика на ноде пишется легко, но особого повода _не_ использовать nginx для статики нету, а плюсы довольно заметны.

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

Если твоя бизнес логика хоть где-то синхронно тормозит (например, что-то считает и ты это не вынес) — она тормозит _все_ запросы. И лучше бы ты отделил логику от статики, чтобы загрузка статики не тормозилась этим. Хотя вообще лучше статику/хранилище файлов/всё такое на отдельные сервера выносить (по причине канала, хотя бы), но это если у тебя есть возможность.

С nginx работает искоробочный letsencrypt вообще без каких-либо значимых телодвижений. Альтернативный клиент для letsencrypt на жс — greenlock — довольно громоздкий, плюс не официальный клиент насколько я знаю. Я бы его в свои зависимости не тянул. По поводу скрутки Node.js и официального клиента letsencrypt я не в курсе, смотреть надо.

Плюс статику nginx отдаёт всё-таки быстрее (там пайплайн отдачи файлов проще и не проходит через V8 с его сборщиком мусора, например), и повода мешать работе бизнес-логики отдачей кучи статики я тоже не вижу.

Короче, лично я использую Node.js за nginx-ом.

ChALkeR ★★★★★
()
Последнее исправление: ChALkeR (всего исправлений: 3)

Сжатие - необходим промежуточный обработчик. Лучше реализовывать на уровне обратного прокси Nginx. Для кэширования результатов запросов все равно лучше использовать Varnish или Nginx. Распределять нагрузку легче с помощью Nginx или HAProxy. Плюс не надо запускать node-приложение от root для доступа к 80 порту.

sadsew
()
Ответ на: комментарий от sadsew

Плюс не надо запускать node-приложение от root для доступа к 80 порту.

Эм. Сейчас 2017. Есть не только CAP_NET_BIND_SERVICE, но и systemd и другие способы подвесить твоё приложение на конкретный порт не давая этому приложению прав рута.

ChALkeR ★★★★★
()
Последнее исправление: ChALkeR (всего исправлений: 1)
Ответ на: комментарий от ChALkeR

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

Shadow ★★★★★
()

Там где полтора человека ходят, у меня нода тоже без nginx работает.

Vit ★★★★★
()

Убивать за nodejs надо!

anonymous
()

Действительно ли ngnix,имеет тут серьезные преимущества? Чем он лучше? Он что, с диска лучше читает, или что?

Его не делают хипстеры‐наркоманы, сующие его везде.

awesomelackware
()

Статика одна на всех - лучше nginx, запросы скажем к базе индивидуальны - лучше nodejs или что-то умеющее асинхронность

Всем этим надо управлять, например анти ddos, тут опять nginx как барьер

По похожей схеме хостится django, поднимается uwsgi и к нему по сокету цепляется nginx

ism ★★★
()
Последнее исправление: ism (всего исправлений: 4)
17 октября 2018 г.
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.