"Зачем нужен 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
Блин, хоть бы кто-то сделал нормальную доку по nginx, а то поставить поставил, а как настроить не знаю.
лень регаться на 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 К, смотря как кто настраивает); поэтому потомок просто отдает весь ответ целиком в буффер и больше не дергается, пока не придет следующий запрос.
>лень регаться на 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).