<div dir="ltr"><div dir="ltr"><br></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">вт, 6 окт. 2020 г. в 16:35, Evgeniy Berdnikov <<a href="mailto:bgx@protva.ru">bgx@protva.ru</a>>:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">On Tue, Oct 06, 2020 at 04:11:37PM +0500, Илья Шипицин wrote:<br>
>    вт, 6 окт. 2020 г. в 15:45, Evgeniy Berdnikov <[1]<a href="mailto:bgx@protva.ru" target="_blank">bgx@protva.ru</a>>:<br>
>       найтись файл, который в буфер не влезет. При любых значениях<br>
>      настроечных<br>
>       параметров. Это нормальная ситуация, причём если Content-Length с<br>
>      апстрима<br>
> <br>
>    с одной стороны я с вами соглашусь, что дефолтное поведение не выглядит<br>
>    отличным.<br>
>    вероятно, если файл больше нельзя сохранять в кеш, то можно просто не<br>
>    пытаться его сохранять,<br>
>    а обойтись тем, что сохранено, остаток дочитать, ну или подождать<br>
>    с другой стороны, вы несчастны с дефолтным поведением - ок, меняете<br>
>    настройку на более комфортную вам<br>
>    и живете с ней.<br>
>    аргументы за "поменять жизнь вообще всем" тяжело заходят. но почему бы не<br>
>    поменять ее конкретно тому,<br>
>    кто несчастен с дефолтом<br>
<br>
 Какая настройка "более комфортная", если апстрим не контролируем?<br></blockquote><div><br></div><div>дефолтные настройки уходят корнями во времена, когда бекендом был апач, для которого</div><div>одновременное поддержание многих открытых соединений являлось узким местом.</div><div><br></div><div>и задача, решаемая многими дефолтными настройками звучит примерно "по возможности</div><div>быстро вычитать файл с апача, и закрыть соединение". <br></div><div><br></div><div>с тех пор ситуация успела поменяться,  C10K умеют вообще, наверное, все сервера <br></div><div>(для справки <a href="https://en.wikipedia.org/wiki/C10k_problem">https://en.wikipedia.org/wiki/C10k_problem</a> )</div><div><br></div><div>не выглядит большой проблемой вычитывать файл и без всякого буфера (на диске) отдавать его</div><div>клиенту. более того, если вы помониторите список рассылки, тут регулярно приходят видеостримеры,</div><div>с жалобами "у нас чуууууть-чууууууть деградировала сеть в сторону клиента и непонятным образом</div><div>выросла в потолок нагрузка на диск прокси". понятно, выросла, потому что ответы стали складываться на диск.</div><div>диск во многих случаях медленнее, чем сеть в сторону апстрима.</div><div><br></div><div>ответственное решение - настроить для себя буферизацию правильно.<br></div><div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
 Например, там хостинг, юзер захочет -- положит 4 гига файл, захочет -- 15G.<br>
 И что, мне из-за этого отказаться от кэша вообще, хотя он в 97% уместен?<br>
 Хотелось бы авторов nginx-a послушать.<br></blockquote><div><br></div><div><br></div><div>ну, я не автор. мне тоже интересно услышать эту историю.<br></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<br>
>       пришёл, она опознаётся сразу. Поэтому обрыв передачи файла клиенту<br>
>       в таких условиях это баг, однозначно.<br>
-- <br>
 Eugene Berdnikov<br>
_______________________________________________<br>
nginx-ru mailing list<br>
<a href="mailto:nginx-ru@nginx.org" target="_blank">nginx-ru@nginx.org</a><br>
<a href="http://mailman.nginx.org/mailman/listinfo/nginx-ru" rel="noreferrer" target="_blank">http://mailman.nginx.org/mailman/listinfo/nginx-ru</a></blockquote></div></div>