ПРОЕКТЫ 


  АРХИВ 


Apache-Talk @lexa.ru 

Inet-Admins @info.east.ru 

Filmscanners @halftone.co.uk 

Security-alerts @yandex-team.ru 

nginx-ru @sysoev.ru 


  СТАТЬИ 


  ПЕРСОНАЛЬНОЕ 


  ПРОГРАММЫ 



ПИШИТЕ
ПИСЬМА












     АРХИВ :: nginx-ru
Nginx-ru mailing list archive (nginx-ru@sysoev.ru)

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: php-fpm upstream pool



On 02.12.2011 18:17, Валентин Бартенев wrote:

А зачем? Health-check нужен на подъем, чтобы не слать запросы
на неработающий бэкенд вообще. И реализовать достаточно просто.

На подъем это другое дело. С этим я не спорю.

так я об этом и спрашивал. именно что на подъем, после того
как backend помечался как неработающий. fail_timeout == 10 секунд
(что слишком много, если backend лежит можно делать проверку через
healtp check хоть раз в секунду) и при этом не будет уходить "налево"
запрос от пользователя, если мы не знаем работает сейчас backend
или нет, и в прошлый раз - он точно был не рабочим. вероятность того,
что он сразу после этого будет уже рабочий - достаточно невысокая.

в результате: и повышение QoS для пользователей и более быстрое восстановление сервера после сбоя. если он уже поднялся - не будет
простаивать 5-10 секунд, а буквально через секунду включится в работу.

У Геннадия было: "и если health check показал, что backend не работает,
тогда нет смысла туда посылать запрос от пользователя".

у Максима было: "Запросы на него будут отправляться 1 раз в fail_timeout."

On 02.12.2011 12:07, Maxim Dounin wrote:

> Алгоритм такой: упавший
> бекенд не будет признан снова работающим, пока не отработает
> успешно хотя бы один запрос, на него отправленный.  Запросы на
> него будут отправляться 1 раз в fail_timeout.
>
> Если запросы долгие (много длиннее fail_timeout, т.е. не просто
> "тяжёлые запросы к базе", а какой-нибудь streaming или long
> polling) это, потенциально, может привести к тому, что бекенд
> (после смерти и оживания обратно) некоторое время будет продолжать
> считаться мёртвым (пока хотя бы один запрос не завершится, или
> клиент его не закроет).  Нагрузка, соответственно, будет идти
> большей частью на другие бекенды.
>
> Есть, впрочем, мнение, что для streaming/long polling подобное
> поведение тоже вполне разумно, и максимум что в подобных ситуациях
> следует сделать - это уменьшить fail_timeout.

--
Best regards,
 Gena

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


 




Copyright © Lexa Software, 1996-2009.