php-fpm upstream pool

[Maxim Dounin]

Hello!

On Fri, Dec 02, 2011 at 03:47:31AM -0500, igor.goncharenko wrote:

[...]

> > Судя по всему, это одно из
> > проявлений вот этого бага:
> > http://trac.nginx.org/nginx/ticket/64
> 
> Да. Очень похоже это оно. Тогда в
> продакшин двигать на 1.0.X нельзя пока :(

Баг потенциально может проявится тогда и только тогда, когда более 
одного бекенда в пуле - мёртвые.  И почти не имеет шансов 
проявится, если при этом более одного живого бекенда.

При этом мёртвый бекенд в пуле - это, вообще говоря, чрезвычайная 
ситуация.

[...]

> > Скорее нет, чем да. 
> > Изменение в целом хорошее,
> > но потенциально 
> > может затронуть работающие
> > конфигурации с долгими
> > запросами и/или 
> > 3rd party балансировщиками.  А
> > чем 1.1.x не устраивает?
> 
> Ситуация такая - продакшин сейчас до
> сих пор на 0.8.54 (балансер). В этой версии
> я тоже замечал присутствие бага
> http://trac.nginx.org/nginx/ticket/64 хотя я больше
> грешил на виртуализацию. С появлением
> ветки 1.0.X была запланирована миграция
> на эту ветку и сейчас вроде как время
> пришло, но появилась задача с fcgi пулом.
> И теперь оказалось, похоже, смысла
> мигрировать на 1.0.X нет - потому что для
> задач балансера этот баг - серьезный.

В 0.8.x в этом месте те же проблемы, и существенно хуже в других 
местах.

> Насчет 1.1.X. Ну во-первых, ветка
> позиционируется как девелопмент,
> соответственно, использовать на
> продакшине можно только в крайнем
> случае.

Отличие stable состоит в первую очередь в том, что её, по 
возможности, не ломают, т.е. обновления с версии на версию не 
должны приносить сюрпризов.  В development нужно быть несколько 
осторожнее с обновлениями (желательно читать changelog).

По стабильности - 1.1.10 сейчас лучше, чем 1.0.10.

> Во-вторых, упомянутый вами
> вопрос с долгими запросами. У меня
> могут быть тяжелые запросы к базе, надо
> подумать как изменение в схеме
> балансинга может на них повлять - судя
> по всему тем, что "живые" бэкенды будут
> нагружены больше чем раньше.

Если вас это пугает - то зачем вы просите сделать merge этого 
изменения в stable? :)

На самом деле там всё не очень страшно.   Алгоритм такой: упавший 
бекенд не будет признан снова работающим, пока не отработает 
успешно хотя бы один запрос, на него отправленный.  Запросы на 
него будут отправляться 1 раз в fail_timeout.

Если запросы долгие (много длиннее fail_timeout, т.е. не просто 
"тяжёлые запросы к базе", а какой-нибудь streaming или long 
polling) это, потенциально, может привести к тому, что бекенд 
(после смерти и оживания обратно) некоторое время будет продолжать 
считаться мёртвым (пока хотя бы один запрос не завершится, или 
клиент его не закроет).  Нагрузка, соответственно, будет идти 
большей частью на другие бекенды.

Есть, впрочем, мнение, что для streaming/long polling подобное 
поведение тоже вполне разумно, и максимум что в подобных ситуациях 
следует сделать - это уменьшить fail_timeout.

> 3rd балансировщиками не пользуюсь.
> 
> Я бы сделал изменение схемы
> балансировки в 1.0.x опциональным и
> выключенным по дефолту, если это
> возможно.

Нет.

> Иначе судя по всему, в моем
> случае, мне придется ждать пока ветка
> 1.1.X не будет переведена в stable.

Up to you.

Maxim Dounin