php-fpm upstream pool

[Maxim Dounin]

Hello!

On Wed, Dec 14, 2011 at 06:51:34PM +0200, Sergej Kandyla wrote:

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

Я стесняюсь спросить - вы 1.1.x (1.1.6+) на данном конкретном "примере из 
жизни" - пробовали?

Maxim Dounin