php-fpm upstream pool

[Gena Makhomed]

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