Hello!

On Fri, Dec 02, 2011 at 06:45:24PM +0200, Gena Makhomed wrote:

> On 02.12.2011 18:17, Валентин Бартенев wrote:
>
> >>А зачем? Health-check нужен на подъем, чтобы не слать запросы
> >>на неработающий бэкенд вообще. И реализовать достаточно просто.
>
> >На подъем это другое дело. С этим я не спорю.
>
> так я об этом и спрашивал. именно что на подъем, после того
> как backend помечался как неработающий. fail_timeout == 10 секунд
> (что слишком много, если backend лежит можно делать проверку через
> healtp check хоть раз в секунду) и при этом не будет уходить "налево"
> запрос от пользователя, если мы не знаем работает сейчас backend
> или нет, и в прошлый раз - он точно был не рабочим. вероятность того,
> что он сразу после этого будет уже рабочий - достаточно невысокая.

Health check'и не отменяют всей той алгоритмики, которая есть
сейчас. Ибо health check может быть успешным, а реальный запрос -
нет.

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

Более быстрого восстановления - не будет, см. выше.

Остаётся, соответственно, небольшое повышение QoS в случае очень
малого трафика (health check успевает раньше) или при сбое (можно
сэкономить единицы реальных запросов, т.к. не нужно посылать на
бекенд реальные запросы, пока health check'и продолжают
fail'иться).

Единственное интересное место, которое мне видится - это делать
другие (меньшие) таймауты для health check'ов. Тогда можно будет,
теоретически, быстрее определять умершие бекенды по health
check'ам, чем по реальным запросам, и сохранять какое-то значимое
количество реальных запросов.

Maxim Dounin

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