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
Hello!
On Wed, Dec 23, 2009 at 01:28:59PM +0200, Bogun Dmitriy wrote:
> В Срд, 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?
В случае, если используется кеш (или proxy_store) - файлы
докачиваются с бекенда, и после этого кладутся в кеш...
> # grep -r proxy_ignore_client_abort /etc/nginx
>
... т.е. фактически неявно включается proxy_ignore_client_abort.
Файлы при этом не удалённые, а вполне себе такие нормальные, лежат
в proxy_temp_path (по окончанию скачивания с бекенда -
перемещаются в proxy_cache_path).
Maxim Dounin
_______________________________________________
nginx-ru mailing list
nginx-ru@xxxxxxxxx
http://nginx.org/mailman/listinfo/nginx-ru
|