Gena Makhomed
December 02, 2011 01:52PM
On 02.12.2011 19:51, Maxim Dounin wrote:

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

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

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

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

что у нас есть:

1. если backend не смог ответить на health check,
то он с вероятностью 99.999% не сможет ответить на реальный запрос.

2. если backend смог ответить на health check, то скорее всего
он сможет ответить и на реальный запрос. (верятность этого 99%)

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

и ответ на вопрос "работает ли этот backend" можно будет
получить раньше, чем через fail_timeout секунд ожидания.

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

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

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

а если есть "живые" backend`ы, то да, можно и не спешить особо,
и ждать fail_timeout секунд, прежде чем слать туда реальный запрос.

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

так это самое неприятное и есть - посылать реальные запросы клиентов
с интервалом в fail_timeout секунд на backend, который не работает.

proxy_connect_timeout по умолчанию 60 секунд, если поставить
1-2 секунды, то живые, но нагруженные backend`ы будут считаться
не работающими и на остальные живые backend`ы в результате
нагрузка еще больше вырастет и их все nginx начнет считать
нерабочими на ближайшие fail_timeout секунд.

а если ставить proxy_connect_timeout больше чем 1-2 секунды, (10-15)
то пользователь такую большую задержку заметит и может не дождавшись
ответа от сервера уйти, посчитав его не работающим или перегруженным,
хотя живые backend`ы были в наличии и ответ он мог получить быстрее.

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

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

--
Best regards,
Gena

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

php-fpm upstream pool

igor.goncharenko November 25, 2011 08:06AM

Re: php-fpm upstream pool

Maxim Dounin November 25, 2011 09:44AM

Re: php-fpm upstream pool

igor.goncharenko November 25, 2011 10:11AM

Re: php-fpm upstream pool

Nefer November 25, 2011 10:30AM

Re: php-fpm upstream pool

igor.goncharenko November 25, 2011 11:24AM

Re: php-fpm upstream pool

igor.goncharenko November 29, 2011 09:39AM

Re: php-fpm upstream pool

Maxim Dounin November 29, 2011 10:16AM

Re: php-fpm upstream pool

igor.goncharenko November 29, 2011 10:48AM

Re: php-fpm upstream pool

Maxim Dounin November 29, 2011 01:16PM

Re: php-fpm upstream pool

igor.goncharenko November 30, 2011 03:08AM

Re: php-fpm upstream pool

igor.goncharenko December 01, 2011 09:19AM

Re: php-fpm upstream pool

Maxim Dounin December 01, 2011 12:14PM

Re: php-fpm upstream pool

igor.goncharenko December 02, 2011 03:47AM

Re: php-fpm upstream pool

Maxim Dounin December 02, 2011 05:08AM

Re: php-fpm upstream pool

Gena Makhomed December 02, 2011 05:54AM

Re[2]: php-fpm upstream pool

Andrey Repin December 02, 2011 08:52AM

Re: php-fpm upstream pool

Gena Makhomed December 02, 2011 10:54AM

Re: php-fpm upstream pool

Валентин Бартенев December 02, 2011 11:04AM

Re: php-fpm upstream pool

Gena Makhomed December 02, 2011 11:12AM

Re: php-fpm upstream pool

Alexandr Gomoliako December 02, 2011 11:12AM

Re: php-fpm upstream pool

Gena Makhomed December 02, 2011 11:16AM

Re: php-fpm upstream pool

Валентин Бартенев December 02, 2011 11:18AM

Re: php-fpm upstream pool

Gena Makhomed December 02, 2011 12:12PM

Re: php-fpm upstream pool

Maxim Dounin December 02, 2011 12:52PM

Re: php-fpm upstream pool

Alexandr Gomoliako December 02, 2011 01:14PM

Re: php-fpm upstream pool

Alexandr Gomoliako December 02, 2011 01:16PM

Re: php-fpm upstream pool

Gena Makhomed December 02, 2011 01:52PM

Re: php-fpm upstream pool

Denis F. Latypoff December 02, 2011 03:02PM

Re: php-fpm upstream pool

Alexandr Gomoliako December 02, 2011 03:14PM

Re: php-fpm upstream pool

Gena Makhomed December 02, 2011 05:18PM

Re: php-fpm upstream pool

Sergej Kandyla December 14, 2011 11:50AM

Re: php-fpm upstream pool

Maxim Dounin December 14, 2011 12:06PM

Re: php-fpm upstream pool

Sergej Kandyla December 14, 2011 12:40PM

Re: php-fpm upstream pool

Denis F. Latypoff December 15, 2011 03:56AM

Re: php-fpm upstream pool

Sergej Kandyla December 15, 2011 11:16AM

Re: php-fpm upstream pool

igor.goncharenko December 14, 2011 10:19AM

Re: php-fpm upstream pool

Maxim Dounin December 14, 2011 11:52AM

Re: php-fpm upstream pool

igor.goncharenko December 14, 2011 02:38PM

Re: php-fpm upstream pool

Gena Makhomed December 14, 2011 12:56PM

Re: php-fpm upstream pool

Alexandr Gomoliako December 14, 2011 01:10PM

Re: php-fpm upstream pool

igor.goncharenko December 14, 2011 02:54PM

Re: php-fpm upstream pool

Alexandr Gomoliako December 14, 2011 03:40PM

Re: php-fpm upstream pool

Andrey N. Oktyabrski December 15, 2011 02:38AM

Re: php-fpm upstream pool

Alexandr Gomoliako December 15, 2011 02:12PM

Re[2]: php-fpm upstream pool

Andrey Repin December 16, 2011 02:52AM

Re: php-fpm upstream pool

Илья Шипицин December 18, 2011 01:46PM

Re: php-fpm upstream pool

Alexandr Gomoliako December 18, 2011 02:32PM

Re: php-fpm upstream pool

Илья Шипицин December 18, 2011 09:40PM

Re: php-fpm upstream pool

Gena Makhomed December 19, 2011 12:12PM

nginx_http_push_module и размер сообщения

Bdfy December 14, 2011 04:38PM

Re: nginx_http_push_module и размер сообщения

Илья Пирогов December 15, 2011 02:54AM

Re: php-fpm upstream pool

mathead December 22, 2011 05:07AM

Re: php-fpm upstream pool

Валентин Бартенев December 24, 2011 08:16AM



Sorry, only registered users may post in this forum.

Click here to login

Online Users

Guests: 271
Record Number of Users: 8 on April 13, 2023
Record Number of Guests: 500 on July 15, 2024
Powered by nginx      Powered by FreeBSD      PHP Powered      Powered by MariaDB      ipv6 ready