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