Apache-Talk @lexa.ru 

Inet-Admins @info.east.ru 

Filmscanners @halftone.co.uk 

Security-alerts @yandex-team.ru 

nginx-ru @sysoev.ru 


   


   


   















      :: nginx-ru
Nginx-ru mailing list archive (nginx-ru@sysoev.ru)

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: proxy vs content-range



В Срд, 23/12/2009 в 12:57 +0300, Maxim Dounin пишет:
> > > Еще раз говорю, знай я что по конкретному location'у будут многогиговые
> > > статические файлы, апач бы никогда не получил туда запрос.
> > это можно легко узнать на backend, если размер отдаваемого файла
> > больше чем ваш разумный предел,
> > то вместо ответа этого файла стоит сделать X-Accel-Redirect
> > то, что на backend находятся большие файлы - это ошибка архитектуры.
> > 
> > логика буферизовать/не буферизовать в зависимости от хидера
> > content-range порочна.
> > этот хидер используется для докачки. в nginx такой костыль никогда не
> > добавят (хотя вы можете и пропатчить).
> 
> Я знаю для чего нужен заголовок content-range, но последнюю вашу фразу
> понять не могу. nginx корректно обрабатывает content-range при прямой
> отдаче статики.
> 
> > > А вот теперь по теме:
> > > Я лишь хочу выяснить и понять логику работы nginx модуля proxy при
> > > облуживании запроса, у которого присутствует заголовок content-range, чтобы
> > > иметь возможность его правильно настроить. О чем я собственно и спросил в
> > > первом сообщении.
> > >
> > >> Если бы у меня была возможность разделить зоны вхостов на статические и
> > >> динамические я бы просто статику прописал в отдачу на прямую nginx'ом и
> > >> эту
> > >> тему не поднимал бы.
> > >>
> > >> Меня больше интересыет логика работы nginx'а при проксировании запроса с
> > >> установленным content-range. Зная ее можно будет планировать обход
> > >> подобных
> > >> проблемных мест.
> > content-range не влияет логику проксирования и не должен этого делать.
> > proxy получает запрос->передаёт его на backend->получает от backend
> > ответ, кладёт в буфер в памяти
> > если размера буфера не хватает пишет ответ на диск.
> 
> Почему же?
> Если мы на backend передадим исходный запрос, с выставленным
> content-range - к нам скорее всего вернется запрошенная, через
> content-range, часть ответа. Как результат все будет работать гладко и
> не так уж заметно портить жизнь при больших файлах. 
> Если же при проксировании мы "потеряем" заголовок content-range, примем
> полностью ответ от backend'а и лишь потом из этого ответа будет
> выковыривать нужный клиенту кусок... это создаст большую проблему при
> многопоточном скачивании больших файлов из-за наличия n копий этого
> самого файла в proxy_temp_path и из-за необходимости копировать довольно
> большой объем данных при запросе лишь малой части из них.
> 
> Судя по тому что я видел у себя, nginx работает по второму сценарию, но
> это на столько нелогично что я пытаюсь тут это уточнить. А мне почему-то
> упорно советуют вместо этого выключить буферизацию при проксировании и
> не вникать в детали.

Заголовок Range от клиента по умолчанию не передаётся на upstream 
когда включено кеширование.  При обычном проксировании - по умолчанию 
передаётся.

Maxim Dounin
Благодарю, это именно то что я хотел узнать.
Есть правда еще один момент - в моем случае, при описываемой проблемной ситуации, nginx держал открытые файловые дескрипторы на уже удаленные с FS файлы. По этому поводу возникает вопрос - в ситуации когда отдается проксируемое тело клиенту и клиент закрывает соединение(выяснено из логов, правда не могу гарантировать что это относится именно к тем "удаленным" файлам) прервет ли nginx получение тела запроса с backend'а преждевременно или дождется его полного получения? И в какой момент производится удаление проксированного тела с FS?
# grep -r proxy_ignore_client_abort /etc/nginx

> ЗЫ 
> # nginx -V
> nginx version: nginx/0.7.62
> configure arguments: --prefix=/usr --conf-path=/etc/nginx/nginx.conf
> --http-log-path=/var/log/nginx/access_log
> --error-log-path=/var/log/nginx/error_log --pid-path=/var/run/nginx.pid
> --http-client-body-temp-path=/var/tmp/nginx/client
> --http-proxy-temp-path=/var/tmp/nginx/proxy
> --http-fastcgi-temp-path=/var/tmp/nginx/fastcgi --with-md5-asm
> --with-md5=/usr/include --with-sha1-asm --with-sha1=/usr/include

Уж сколько раз твердили миру...

$ ./configure --help | grep with-md5=
  --with-md5=DIR                     set path to md5 library sources
$ ./configure --help | grep with-sha1=
  --with-sha1=DIR                    set path to sha1 library sources

Please note: *sources*.
Это скорее к автору ебилда.
_______________________________________________
nginx-ru mailing list
nginx-ru@xxxxxxxxx
http://nginx.org/mailman/listinfo/nginx-ru


 




Copyright © Lexa Software, 1996-2009.