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 в 05:22 +0300, Ihalainen Nickolay пишет:
> Еще раз говорю, знай я что по конкретному 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 работает по второму сценарию, но это на столько нелогично что я пытаюсь тут это уточнить. А мне почему-то упорно советуют вместо этого выключить буферизацию при проксировании и не вникать в детали.

ЗЫ
# 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 --without-http_fastcgi_module --with-http_ssl_module --with-http_stub_status_module --add-module=/var/tmp/portage/www-servers/nginx-0.7.62/work/nginx_uploadprogress_module

OS gentoo linux-2.6.28-hardened-r7
_______________________________________________
nginx-ru mailing list
nginx-ru@xxxxxxxxx
http://nginx.org/mailman/listinfo/nginx-ru


 




Copyright © Lexa Software, 1996-2009.