Re: логика fail timeo­ut в­­­ апстриме.

[vinny13 at land.ru]

> 
> А в чём смысл?  Если на бекенде проблемы - то все рабочие процессы 
> рано или поздно об этом узнают.
> 
Смысл в следующем. Приложение-бекенд очень медленное и нестабильное - для его работы
приходиться выставлять timeout'ы в 30-50 секунд. В дополнение к этому итоговая страница, которая отдаётся браузеру,
собирается со всего апстрима, причём последовательно. Т.е. при проблемах на одном бекенде конечные страницы всех клиентов
начинают собираться в рамках  этих 30-50 секунд умноженных на число запросов попавших на проблемный бекенд, что делает систему практически неработоспособной. Переписать\улучшить приложение в обозримом будущем ресурсов нет.
Если же при первых симптомах "отстреливать" проблемный бекенд то, _теоретически_, это должно улучшить ситуацию.
Есть ещё одна мысль - все запросы в рамках одной сессии ( сессия здесь - сборка конечной страницы ), перенаправлять
на один бекенд, однозначно выбираемый из апстрима  в соответствии с некоторым кастомным HTTP заголовком, но как это реализовать в nginx я пока не изучал - возможно Вы мне подскажете направление в котором двигаться  :)