вт, 6 окт. 2020 г. в 16:35, Evgeniy Berdnikov <b...@protva.ru>:
> On Tue, Oct 06, 2020 at 04:11:37PM +0500, Илья Шипицин wrote: > > вт, 6 окт. 2020 г. в 15:45, Evgeniy Berdnikov <[1]b...@protva.ru>: > > найтись файл, который в буфер не влезет. При любых значениях > > настроечных > > параметров. Это нормальная ситуация, причём если Content-Length с > > апстрима > > > > с одной стороны я с вами соглашусь, что дефолтное поведение не > выглядит > > отличным. > > вероятно, если файл больше нельзя сохранять в кеш, то можно просто не > > пытаться его сохранять, > > а обойтись тем, что сохранено, остаток дочитать, ну или подождать > > с другой стороны, вы несчастны с дефолтным поведением - ок, меняете > > настройку на более комфортную вам > > и живете с ней. > > аргументы за "поменять жизнь вообще всем" тяжело заходят. но почему > бы не > > поменять ее конкретно тому, > > кто несчастен с дефолтом > > Какая настройка "более комфортная", если апстрим не контролируем? > дефолтные настройки уходят корнями во времена, когда бекендом был апач, для которого одновременное поддержание многих открытых соединений являлось узким местом. и задача, решаемая многими дефолтными настройками звучит примерно "по возможности быстро вычитать файл с апача, и закрыть соединение". с тех пор ситуация успела поменяться, C10K умеют вообще, наверное, все сервера (для справки https://en.wikipedia.org/wiki/C10k_problem ) не выглядит большой проблемой вычитывать файл и без всякого буфера (на диске) отдавать его клиенту. более того, если вы помониторите список рассылки, тут регулярно приходят видеостримеры, с жалобами "у нас чуууууть-чууууууть деградировала сеть в сторону клиента и непонятным образом выросла в потолок нагрузка на диск прокси". понятно, выросла, потому что ответы стали складываться на диск. диск во многих случаях медленнее, чем сеть в сторону апстрима. ответственное решение - настроить для себя буферизацию правильно. > Например, там хостинг, юзер захочет -- положит 4 гига файл, захочет -- > 15G. > И что, мне из-за этого отказаться от кэша вообще, хотя он в 97% уместен? > Хотелось бы авторов nginx-a послушать. > ну, я не автор. мне тоже интересно услышать эту историю. > > > пришёл, она опознаётся сразу. Поэтому обрыв передачи файла клиенту > > в таких условиях это баг, однозначно. > -- > Eugene Berdnikov > _______________________________________________ > nginx-ru mailing list > nginx-ru@nginx.org > http://mailman.nginx.org/mailman/listinfo/nginx-ru
_______________________________________________ nginx-ru mailing list nginx-ru@nginx.org http://mailman.nginx.org/mailman/listinfo/nginx-ru