On 14.12.2011 19:05, Maxim Dounin wrote:
>
>> Геннадий прав. Проблемма актуальная.
>> Nginx потому так и популярен, что разработчик прислушивается к
>> коммунити и реализовывает нужные механизмы,
>> в том числе и обработку ситуаций "кривых бекендов".
>>
>> Сам себе злой буратино с писаниной на пхп - это всё идет лесом при
>> командной работе, где за бекенд и приложение отвечают и
>> разрабатывают совершенно другие люди.
>>
>> Пример из жизни.
>> Nginx load-balancer с ip_hash , бекенды - два томката.
>>
>> proxy_connect_timeout, proxy_read_timeout были задраны ощутимо, потому как для томката (и вообще сложного приложения) отрабатывать запрос долго - это скажем, нормально.
>> В один из моментов томкаты что-то не поделили, и второй томкат отвалился, но при этом продолжал принимать соединения.
>>
>> Картина стала следующей: Юзер конектится на приложение (лоад-балансер отправляет запрос в рандоме и попадает на дохлый бекенд), юзер ждет 2 минуты, потом страница резко открывается (нжинкс не получил ответа от дохлого бекенда и послал запрос на второй бекенд). Отлично. Юзер шлет второй запрос к другой страничке - ситуация повторяется.
>>
>>
>> Я бы сильно предпочел в этой ситуации, чтобы нжинкс сам проверял
>> бекенды на "дохлость", и если бекенд не отвечает - то не слать на
>> него запросы вообще, покуда он не подымется.
>>
>> Фича востребованная. Если вам она не нужна, то это не значит, что
>> она не нужна вообще.
>>
> Я стесняюсь спросить - вы 1.1.x (1.1.6+) на данном конкретном "примере из
> жизни" - пробовали?
>
>

нет. Это было пол года назад, еще до релиза 1.1.6, (и на nginx 0.8.54).

Я не знал, что в 1.1.6 данный функционал переработан.
Спасибо.


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