> Никак - какому рабочему процессу повезло получить соединение из
> ядра, тот и будет обрабатывать запросы в данном соединении.
>
Тогда в моём случае получается, что чем меньше воркеров, тем быстрее
и менее безболезненно для клиента "весь" nginx "узнает" о проблемном
бекенде и перестанет посылат
>
> А в чём смысл? Если на бекенде проблемы - то все рабочие процессы
> рано или поздно об этом узнают.
>
Смысл в следующем. Приложение-бекенд очень медленное и нестабильное - для его
работы
приходиться выставлять timeout'ы в 30-50 секунд. В дополнение к этому итоговая
страница, которая отд
> Да, т.к. это синтетические тесты, то единичные случаи, но в "реале" хотелось
> бы
> что бы при определённом соотношении max_fail/fail_timeout сервер полностью
> выключался на время из апстрима.
>
> Ваша фраза о том, что состояние upstream-серверов - для каждого рабочего
> процесса своё,
> по
Да, т.к. это синтетические тесты, то единичные случаи, но в "реале" хотелось бы
что бы при определённом соотношении max_fail/fail_timeout сервер полностью
выключался на время из апстрима.
Ваша фраза о том, что состояние upstream-серверов - для каждого рабочего
процесса своё,
подтвердила мои под
В том-то и дело что в логе проскакивает только
upstream timed out (60: Operation timed out) while connecting to upstream,
и всё дальше работает как ни в чём не бывало..
no live upstreams появляется только когда действительно нет живых бекендов .
> > Здравствуйте.
> >
> > Имеется слудующий апстри
Здравствуйте.
Имеется слудующий апстрим:
upstream web1 { server 10.10.10.1 fail_timeout=180; server 10.10.10.2;
}Т.е. насколько я понимаю, при возникновении хотя бы одного таймаута за 180
секунд, сервер должен "выбывать" из апстрима на те же 180 секунд. Но, судя по
tcpdump'у на бекенде
