14.12.2011, 23:51, "Sergej Kandyla" <sk@hlsrv.com>:
> On 02.12.2011 21:59, Denis F. Latypoff wrote:
>
>>>> Остаётся, соответственно, небольшое повышение QoS в случае очень
>>>> малого трафика (health check успевает раньше) или при сбое (можно
>>>> сэкономить единицы реальных запросов, т.к. не нужно посылать на
>>>> бекенд реальные запросы, пока health check'и продолжают
>>>> fail'иться).
>>> так это самое неприятное и есть - посылать реальные запросы клиентов
>>> с интервалом в fail_timeout секунд на backend, который не работает.
>> всем пофиг. никто из юзеров тебе не напишет, что его послали на
>> неработающий бэкенд. да и фиг с ним, остальные 100000 тысяч довольны.
>> Мы ведь говорим о высокой нагрузке? Nginx же!
>>> proxy_connect_timeout по умолчанию 60 секунд, если поставить
>>> 1-2 секунды, то живые, но нагруженные backend`ы будут считаться
>>> не работающими и на остальные живые backend`ы в результате
>>> нагрузка еще больше вырастет и их все nginx начнет считать
>>> нерабочими на ближайшие fail_timeout секунд.
>>>
>>> а если ставить proxy_connect_timeout больше чем 1-2 секунды, (10-15)
>>> то пользователь такую большую задержку заметит и может не дождавшись
>>> ответа от сервера уйти, посчитав его не работающим или перегруженным,
>>> хотя живые backend`ы были в наличии и ответ он мог получить быстрее.
>> Да блин. Если ты (это собирательный образ) только и умеешь что писать на
>> PHP, то сам себе злой буратино, тебе и апач подойдет, с твоими-то знаниями.
>> Зачем тебе nginx, которые неведомым образом позаботится обо всех твоих пяти
>> юзерах? (Четверых сразу да, а пятого погонять погонять по всем бекендам,
>> включить AI, и все-таки отдать работающему бекенду).
>> Если думаешь иначе - пиши пачт.
>
> Геннадий прав. Проблемма актуальная.
> Nginx потому так и популярен, что разработчик прислушивается к коммунити
> и реализовывает нужные механизмы,
> в том числе и обработку ситуаций "кривых бекендов".
>
> Сам себе злой буратино с писаниной на пхп - это всё идет лесом при
> командной работе, где за бекенд и приложение отвечают и разрабатывают
> совершенно другие люди.
>
> Пример из жизни.
> Nginx load-balancer с ip_hash , бекенды - два томката.
>
> proxy_connect_timeout, proxy_read_timeout были задраны ощутимо, потому как для томката (и вообще сложного приложения) отрабатывать запрос долго - это скажем, нормально.
О какой высокой нагрузке идет речь? У нас тут хайлоад так-то...
> В один из моментов томкаты что-то не поделили, и второй томкат отвалился, но при этом продолжал принимать соединения.
>
> Картина стала следующей: Юзер конектится на приложение (лоад-балансер отправляет запрос в рандоме и попадает на дохлый бекенд), юзер ждет 2 минуты, потом страница резко открывается (нжинкс не получил ответа от дохлого бекенда и послал запрос на второй бекенд). Отлично. Юзер шлет второй запрос к другой страничке - ситуация повторяется.
>
> Я бы сильно предпочел в этой ситуации, чтобы нжинкс сам проверял бекенды
> на "дохлость"
И этим самым добил бекенда.
>, и если бекенд не отвечает - то не слать на него запросы
> вообще, покуда он не подымется.
>
> Фича востребованная. Если вам она не нужна, то это не значит, что она не
> нужна вообще.
>
--
br, Denis F. Latypoff.
_______________________________________________
nginx-ru mailing list
nginx-ru@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx-ru