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 минуты, потом страница резко открывается (нжинкс не получил ответа от дохлого бекенда и послал запрос на второй бекенд). Отлично. Юзер шлет второй запрос к другой страничке - ситуация повторяется.


Я бы сильно предпочел в этой ситуации, чтобы нжинкс сам проверял бекенды
на "дохлость", и если бекенд не отвечает - то не слать на него запросы
вообще, покуда он не подымется.

Фича востребованная. Если вам она не нужна, то это не значит, что она не
нужна вообще.

_______________________________________________
nginx-ru mailing list
nginx-ru@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx-ru