>лень регаться на 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).