предлагаю немного поменять логику 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