предлагаю немного поменять логику proxy_next_upstream
Илья Шипицин
chipitsine at gmail.com
Mon Aug 12 10:59:53 UTC 2013
Добрый день!
мы столкнулись с ситуацией такого характера.
есть веб-приложения, которые долго отвечают, в отношении них
справедливо, что лучше запрос отправить не более одного раза
(например, это может быть разнесения платежа, на 20 фронтов платеж
разнесется 20 раз).
с другой стороны, хотелось бы отличать "таймаут при отправке данных"
от "тайаута при чтении данных".
в случае, если мы не можем отправить данные - нормально уйти на
следующий хост. если мы уходим в таймаут при чтении - на следующий
хост лучше не уходить, может быть массовый "расстрел" (разнесение
платежа 20 раз из 20).
патч вложил.
Илья Шипицин
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 504.patch
Type: application/octet-stream
Size: 407 bytes
Desc: not available
URL: <http://mailman.nginx.org/pipermail/nginx-ru/attachments/20130812/96986a15/attachment.obj>
Подробная информация о списке рассылки nginx-ru