Re: php-fpm upstream pool

[Denis F. Latypoff <latypoff@xxxxxxxxx>]

03.12.2011, 01:51, "Gena Makhomed" <gmm@xxxxxxxxx>:
> 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, который не работает.

всем пофиг. никто из юзеров тебе не напишет, что его послали на
неработающий бэкенд. да и фиг с ним, остальные 100000 тысяч довольны.
Мы ведь говорим о высокой нагрузке? Nginx же!

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

Да блин. Если ты (это собирательный образ) только и умеешь что писать на
PHP, то сам себе злой буратино, тебе и апач подойдет, с твоими-то знаниями.
Зачем тебе nginx, которые неведомым образом позаботится обо всех твоих пяти
юзерах? (Четверых сразу да, а пятого погонять погонять по всем бекендам,
включить AI, и все-таки отдать работающему бекенду).
Если думаешь иначе - пиши пачт.

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

Ребята, куда вас вообще понесло? Лучше учите народ правильно писать
бекенды, а не придумывайте зеленки для их кровоточащих ран.
Nginx - open source. Доволен - скажи спасибо. Не доволен - пиши пачт.

И Гена, завязывай троллить в каждом топике. Или тебе за это платят?

Ну и - с пятницей!

-- 
br, Denis F. Latypoff.

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