LINUX.ORG.RU

[webdev] Зачем нужен frontend web server?

 


0

1

Вечер добрый.

У меня тут на досуге возник следующий вопрос. Например у нас есть како-то веб сервер в духе node.js, twisted, etc. Представим что на нем крутится что-то более менее динамичное, например тот же чат. Обычно перед ним ставят какой-то «продвинутый» сервер (nginx). Вот у меня собственно и возник вопрос, что это нам дает? Очень в общем я примерно понимаю, но внятно ничего сформулировать не могу. Хочется конкретных примеров из жизни.
Статьи и книги по этому вопросу wellcome.

★★★★★

Кеширование, балансировка, виртуалхосты, реврайты, контроль доступа, SSL, геолокация.

power
()

Во-первых, такой сервер обычно занимается отдачей статики.

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

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

Кстати, да. Еще одно хорошее применение — выводить 502 :)

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

Вот это меня и тревожит. Пускай у нас есть Twisted application, и пару сот постоянных подключений, nginx ведь будет держать много work'еров жрущих память, ему нужно будет держать все эти «пару сот» соединений. Разве нет?

Представим что никакой статики и кеширования у нас нет.

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

nginx ведь будет держать много work'еров жрущих память, ему нужно будет держать все эти «пару сот» соединений. Разве нет?

Он же асинхронный.

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

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

INFOMAN ★★★★★
()

Для чата нафиг сервер не нужен: хватит «голых» вебсокетов.

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

nginx ведь будет держать много work'еров жрущих память, ему нужно будет держать все эти «пару сот» соединений.

Сысоев говорит, что на 10000 неактивных HTTP keep-alive соединений расходуется около 2.5M памяти

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

Сысоев говорит, что на 10000 неактивных HTTP keep-alive соединений расходуется около 2.5M памяти

Ухты! Круто!

urxvt ★★★★★
() автор топика

Спасибо всем за помощь, ребята и девчата.

urxvt ★★★★★
() автор топика

Потому что заметное количество серверов приложений тратят довольно много ресурсов на одно соединение, по этому дешевле проксировать HTTP через отдельный «легкий» фронт-сервер. Ну и плюс у того-же nginx есть всякие хитрые фишки вроде ограничения количества/частоты соединений с одного IP или на один скрипт и прочие анти-DDoS фишки

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

воркер основного сервера не будет тупо висеть в памяти вместе со всей логикой приложения всё то время

намекаете на апач+пхп? но ведь вопрос о twisted и node.js, а они такими проблемами не страдают

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

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

бред какойто. twisted не создает процесс/тред на каждое соединение, он совсем по другому принципу работает

redixin ★★★★
()

Хочется конкретных примеров из жизни

У меня nginx: а) аутентификация по TLS; б) URL-rewriter для REST MongoDB. Если была бы высокая нагруза, использовал бы его еще как интерфейс к memcached.

Macil ★★★★★
()

и да, в nginxе перед нодой или твистедом смысла не много. он есть разве что при использовании фич которые умеет nginx но не умеет сабж, вроде ограничения конектов, ssl, балансировки в конце концов.

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

Представим что никакой статики и кеширования у нас нет.

Если есть статика, меня стремает, что твистед должен заниматься таким холопским делом, как ее отдача.

А если нет статики, то смысла не вижу. Разве что балансировать нагрузку, да и то, я бы и балансировщик писал на том же твистеде, учитывая, что есть txLoadBalancer и Ampoule, которыми можно как угодно кудесничать.

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

twisted не создает процесс/тред на каждое соединение, он совсем по другому принципу работает

А это неважно. Главное что nginx служит общим знаменателем для сайтов (иначе каждому twisted по своему айпишнику придётся выделять) с продвинутыми средствами балансировки, защиты итп. Всё это можно притянуть в приложение, но зачем замусоривать код и решать задачу которая уже решена?

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

А это неважно.

Да, конечно. Пусть все думают что twisted создает процесс на каждое соединение ок.

Главное что nginx служит общим знаменателем для сайтов (иначе каждому twisted по своему айпишнику придётся выделять)

С какой такой радости им нужно много айпишников?

с продвинутыми средствами балансировки, защиты итп.

Это где такие? В nginx?

И да, повторюсь: для балансировки и базовых анти-ддос штук конечно да, nginx годится.

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

Пусть все думают что twisted

А я не к этому говорил, не надо передёргивать.

С какой такой радости им нужно много айпишников?

Не, ну если всё работает от одного юзера то не потребуется.

В nginx?

Именно. Хотя, про балансировку я загнул.

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

Задам вопрос по-другому: что есть лучше чем nginx+самопальные скрипты для защиты сервера?

Изначально вопрос был «для чего nginx перед твистедом или нодой». Ответ: он там может быть полезен лишь в качестве балансировщика в случае большого количества железа, либо в качестве подобия анти-ддос решения.

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

redixin ★★★★
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.