Re: php-fpm upstream pool

[Sergej Kandyla <sk@xxxxxxxxx>]

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@xxxxxxxxx
http://mailman.nginx.org/mailman/listinfo/nginx-ru