proxy vs content-range

[Bogun Dmitriy]

В Втр, 22/12/2009 в 20:45 +0300, Sergey Shepelev пишет:

> >> Сегодня возникла одна проблема, которая поставила передо мной вопрос, как
> >> работает сохранение ответа backend'а в proxy_temp_path в случае наличия в
> >> запросе content-range.
> >>
> >> Моя проблема заключалась в том, что файлик размером в ~4gb стала тянуть
> >> качалка в ~10 потоков, что привело к очень большой нагрузке на FS и
> >> окончанию на ней места. Причем место занимали файлы уже удаленные с FS но
> >> еще не закрытые nginx'ом.
> >>
> >> Конфиг вхоста:
> >>
> >> server {
> >>     listen      1.1.1.1;
> >>
> >>     server_name .vhost.dom;
> >>
> >>     client_max_body_size 200m;
> >>
> >>     access_log  /var/log/nginx/vhost-access.log generic;
> >>     error_log   /var/log/nginx/vhost-error.log info;
> >>
> >>     root /srv/vhost.dom/www/htdocs;
> >>
> >>     location / {
> >>         proxy_pass         http://upstr_vhost;
> >>         proxy_set_header   Host             $host;
> >>         proxy_set_header   X-Real-IP        $remote_addr;
> >>         proxy_set_header   X-Forwarded-For  $proxy_add_x_forwarded_for;
> >>     }
> >> }
> >>
> >> На upstream'е обыкновенный apache, который отдавал файл с ФС. Настроить
> >> отдачу напрямую не всегда возможно, т.к. за содержимое вхоста "отвечает"
> >> другой человек...
> >>
> >> Направьте в сторону информации о работе модуля proxy при наличии заголовка
> >> content-range.
> >
> > proxy_buffering off;
> >
> > Смысл тогда держать nginx?
> 
> Смысл в том, что nginx не начинает на каждый запрос тяжелый OS поток,
> следовательно, может принять запросы от тысячи клиентов одновременно.
> Ещё мне лично синтаксис конфига нравится больше, чем у других веб
> серверов.

"Тяжелый OS поток"? В смысле - процесс? Для начала в *nix системе fork()
более-менее дешевая операция. Но в данном случае вопрос не в этом, а в
том куда nginx денет этот принятый запрос? Уж не передаст ли он его
куда-нибудь на backend для обработки, и не понадобится ли этому
backend'у создать "тяжелый OS поток" для обслуживания этого запроса?
Но по хорошему это не касается обсуждаемой темы.

> nginx проксирует запрос апачу, апач читает огроменный файл с диска
> используя какой-то буфер для чтения этого файла, в любом случае между
> диском и апачом существует как минимум один буфер, в который попадают
> данные. Вы добавляете ещё один. Вот теперь вы мне ответьте на тот же
> самый вопрос. Какой смысл держать nginx.

Апач не так "стар" как вам хочется, он прекрасно умеет использовать
sendfile. Но это опять не в тему.

> Если для вас смысл в nginx - добавить ещё одно звено буферизации
> статических файлов, тогда ещё proxy_cache надо включить и ещё squid
> поставить.

Смысл nginx'а для меня, возможность более быстрого обслуживания запросов
к динамическим страницам. Благодаря буферизации ответа backend'а на диск
или в буферы nginx'а с backend'а снимается необходимость простоя в
ожидании пока клиент заберет данные.

Но проблема, моя лично, заключается в том, что я не всегда могу
определить где будет статика а где динамика.
Еще раз говорю, знай я что по конкретному location'у будут многогиговые
статические файлы, апач бы никогда не получил туда запрос.

А вот теперь по теме:
Я лишь хочу выяснить и понять логику работы nginx модуля proxy при
облуживании запроса, у которого присутствует заголовок content-range,
чтобы иметь возможность его правильно настроить. О чем я собственно и
спросил в первом сообщении.

> > Если бы у меня была возможность разделить зоны вхостов на статические и
> > динамические я бы просто статику прописал в отдачу на прямую nginx'ом и эту
> > тему не поднимал бы.
> >
> > Меня больше интересыет логика работы nginx'а при проксировании запроса с
> > установленным content-range. Зная ее можно будет планировать обход подобных
> > проблемных мест.


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://nginx.org/pipermail/nginx-ru/attachments/20091222/3a9f3ca5/attachment.html>