У нас несколько специфическая задача, к тому же отдаются большие файлы. <div><br></div><div>В принципе хорошо было бы чтобы в документации указывалось что при таких директивах не будут работать следующие... Т.к. ожидаешь одно поведение, а зашито другое. А выход из данной проблемы я нашел, точнее мне подсказал M. Doulin, за что ему огромная благодарность.<div>
<br><div>>если отключить буферезацию на диск - nginx будет тянуть ровно столько, на сколько хватит буферов в памяти. остальное не будет прочитано из соединения с бекендом.<br><span class="Apple-style-span" style="font-weight: bold;">>proxy_max_temp_file_size 0;</span><br>
</div><div><br><div class="gmail_quote">20 июля 2009 г. 20:03 пользователь Dmitriy MiksIr <span dir="ltr"><<a href="mailto:miksir@maker.ru">miksir@maker.ru</a>></span> написал:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
<br>
Скажите, а в чем смысл limit_rate без буфферизации? Дабы занять побольше коннектов у бекенда? Одна из фиункциональных задач легких серверов - быстрое освобождение бекенда для медленных клиентов, а вы хотите обратного. Какой-то анти-паттерн прям.<br>
<br>
SaveFrom.net пишет:<div><div></div><div class="h5"><br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Здравствуйте, Игорь.<br>
Благодарю Вас за ответ. Скажите пожалуйста, как следует понимать Ваш ответ? Что это ожидаемое поведение nginx и ошибкой не является? Если да, то на сколько проблематично будет написание патча исправляющего неработоспособность данной директивы и возможно ли это концептуально?<br>
Если все же считаете данное поведение на вполне корректным, то планируете ли Вы исправление ошибки в ближайший обновлениях?<br>
С уважением, Антон.<br>
</blockquote>
<br>
<br>
</div></div></blockquote></div><br></div></div></div>