The OpenNET Project / Index page

[ новости /+++ | форум | теги | ]

форумы  помощь  поиск  регистрация  майллист  ВХОД  слежка  RSS
"OpenNews: FAQ зачем нужен nginx и схема фронтенд-бэкенд"
Вариант для распечатки  
Пред. тема | След. тема 
Форумы Разговоры, обсуждение новостей (Public)
Изначальное сообщение [Проследить за развитием треда]

"OpenNews: FAQ зачем нужен nginx и схема фронтенд-бэкенд"  
Сообщение от opennews (ok) on 18-Апр-07, 10:47 
"Зачем нужен nginx (http://ospf-ripe.livejournal.com/754.html)" - FAQ зачем нужен nginx и схема фронтенд-бэкенд.

URL: http://ospf-ripe.livejournal.com/754.html
Новость: http://www.opennet.me/opennews/art.shtml?num=10471

Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

 Оглавление

Сообщения по теме [Сортировка по времени, UBB]


1. "FAQ зачем нужен nginx и схема фронтенд-бэкенд"  
Сообщение от SubGun email(ok) on 18-Апр-07, 10:47 
Блин, хоть бы кто-то сделал нормальную доку по nginx, а то поставить поставил, а как настроить не знаю.
Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

2. "FAQ зачем нужен nginx и схема фронтенд-бэкенд"  
Сообщение от zuborg on 18-Апр-07, 14:32 
лень регаться на LJ, отвечу сюда, мож кому-то пригодится:
при всех плюсах у nginx есть и минуса, которые не дают ему считаться идеальным решением для акселерации http-трафика
1) неправильныя модель балансировки
http://www.lexa.ru/nginx-ru/msg08943.html
2) отсутствие поддержки HTTP/1.1 при передаче запросов на бекенд. На практике это означает что для каждого запроса, передающегося на бекенд, создается новое TCP-соединение. То есть на бекенде "KeepAlive on" можно спокойно отключать - он все равно не используется. Люди, занимающиеся оптимизацией серверов, знают чем чревато отключение keep-alive в плане продуктивности серверов.
3) nginx - дополнительное звено. Не обязательно лишнее, но дополнительная задержка при обработке запроса возникает. Кроме этого, увеличивается потребление памяти ядра для сокетов - запрос надо не только забуферизировать для отдачи клиенту, но и получить от бекенда.

Плюс к этому, в статье преувеличивается значение большого кол-ва потомков при обработке множества паралельных запросов. Во первых, есть AcceptFilterHTTP. Во вторых, потомки значительную часть памяти (обычно сегмент кода) процесса разделяют между собой (например на всего 1Г RAM запущено 1000 потомков каждый по 4-5М, и ещё память на дисковый кеш остается). В третьих, обычно отдаваемый файл полностью помещается в исходящий буффер сокета (64 или 128 К, смотря как кто настраивает); поэтому потомок просто отдает весь ответ целиком в буффер и больше не дергается, пока не придет следующий запрос.

Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

3. "FAQ зачем нужен nginx и схема фронтенд-бэкенд"  
Сообщение от citrin email(??) on 18-Апр-07, 16:30 
>лень регаться на LJ, отвечу сюда, мож кому-то пригодится:
>при всех плюсах у nginx есть и минуса, которые не дают ему
>считаться идеальным решением для акселерации http-трафика
>1) неправильныя модель балансировки
>http://www.lexa.ru/nginx-ru/msg08943.html

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

>2) отсутствие поддержки HTTP/1.1 при передаче запросов на бекенд. На практике это
>означает что для каждого запроса, передающегося на бекенд, создается новое TCP-соединение.
>То есть на бекенде "KeepAlive on" можно спокойно отключать - он
>все равно не используется. Люди, занимающиеся оптимизацией серверов, знают чем чревато
>отключение keep-alive в плане продуктивности серверов.

Для хождения к бекенду наличие KeepAlive практически ничего не дает.

KeepAlive нужны для клиентов, подключенных по сравнительно медленным каналам, поскольку позволяет экономить на TCP Handshake и slow start.

При подключении фронтенда к бэкенду это не актуально - сеть между ними быстрая и без потерь, а "разгонять" окно не нужно как минимум во freebsd 6 где есть tcp hostcache

>3) nginx - дополнительное звено. Не обязательно лишнее, но дополнительная задержка при
>обработке запроса возникает.

По сравнению с генерацией ответа на бэкенде (50 ms - 500 ms) эта задержка очень небольшая (3 - 5 ms).

Кроме этого, увеличивается потребление памяти ядра для сокетов
>- запрос надо не только забуферизировать для отдачи клиенту, но и
>получить от бекенда.

В том то и дело, что в nginx его буферезировать лучше чем задерживать тяжелый бэкенд.

>
>Плюс к этому, в статье преувеличивается значение большого кол-ва потомков при обработке
>множества паралельных запросов. Во первых, есть AcceptFilterHTTP.

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

>часть памяти (обычно сегмент кода) процесса разделяют между собой

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

Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

Архив | Удалить

Индекс форумов | Темы | Пред. тема | След. тема
Оцените тред (1=ужас, 5=супер)? [ 1 | 2 | 3 | 4 | 5 ] [Рекомендовать для помещения в FAQ]




Партнёры:
PostgresPro
Inferno Solutions
Hosting by Hoster.ru
Хостинг:

Закладки на сайте
Проследить за страницей
Created 1996-2024 by Maxim Chirkov
Добавить, Поддержать, Вебмастеру