php-fpm upstream pool

Sergej Kandyla sk на hlsrv.com
Ср Дек 14 17:41:49 UTC 2011


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