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