Re: Ограничение соеди нений с backend

[Sergej Kandyla <sk.paix@xxxxxxxxx>]

Vladimir Latyshev пишет:
>     Таки да. Извиняюсь. Костыльный вариант - поставить перед nginx ещё
>     один nginx :).
>     Также мне помогал маленький backlog и лимит коннектов в апаче
>     ограничением MaxClients + понижение таймаутов проксирования в nginx.
>
>
> а вот это тема!
> я ее продумывал чуть ранее в другом варианте, там не получалось, а вот 
> сейчас же вижу так:
> на внутреннем ставим вышеобозначенной мной схемой ограничение быстрому 
> "клиенту" - внешнему nginx, которое эквивалентно передается апачу
> а внешний nginx тупо проксирует все, что ему отдает внутренний
>
> костыль, но в итоге вроде бы получаем именно то, что нужно, тем более 
> что и один nginx  - тоже костыль :)
один nginx - это не касталыль а распределенная архитектура frontend - 
backend.
Мне кажется вы пытаетесь слишком усложнить себе жизнь, и выгоды от этого 
очень сомнительны.
Если вы рассматриваете на бекенде (апач) один виртуалхост, то
статику для него отдаем nginxом, а проксируем только динамику.

по дефолту стоит
proxy_buffering     on;

что значит, nginx будет пытаться принять максимально быстро ответ от 
бекенда.
Все! дальше бекенд свободен! Медленных клиентов обслуживает nginx.

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

--
Best wishes, Sergej Kandyla
Всегда улыбайтесь жизни и жизнь всегда улыбнется вам!