<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 TRANSITIONAL//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV="Content-Type" CONTENT="text/html; CHARSET=UTF-8">
<META NAME="GENERATOR" CONTENT="GtkHTML/3.28.1">
</HEAD>
<BODY>
В Втр, 22/12/2009 в 20:45 +0300, Sergey Shepelev пишет:
<BLOCKQUOTE TYPE=CITE>
<PRE>
>> Сегодня возникла одна проблема, которая поставила передо мной вопрос, как
>> работает сохранение ответа 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 <A HREF="http://upstr">http://upstr</A>_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 поток,
следовательно, может принять запросы от тысячи клиентов одновременно.
Ещё мне лично синтаксис конфига нравится больше, чем у других веб
серверов.
</PRE>
</BLOCKQUOTE>
"Тяжелый OS поток"? В смысле - процесс? Для начала в *nix системе fork() более-менее дешевая операция. Но в данном случае вопрос не в этом, а в том куда nginx денет этот принятый запрос? Уж не передаст ли он его куда-нибудь на backend для обработки, и не понадобится ли этому backend'у создать "тяжелый OS поток" для обслуживания этого запроса?<BR>
Но по хорошему это не касается обсуждаемой темы.
<BLOCKQUOTE TYPE=CITE>
<PRE>
nginx проксирует запрос апачу, апач читает огроменный файл с диска
используя какой-то буфер для чтения этого файла, в любом случае между
диском и апачом существует как минимум один буфер, в который попадают
данные. Вы добавляете ещё один. Вот теперь вы мне ответьте на тот же
самый вопрос. Какой смысл держать nginx.
</PRE>
</BLOCKQUOTE>
Апач не так "стар" как вам хочется, он прекрасно умеет использовать sendfile. Но это опять не в тему.
<BLOCKQUOTE TYPE=CITE>
<PRE>
Если для вас смысл в nginx - добавить ещё одно звено буферизации
статических файлов, тогда ещё proxy_cache надо включить и ещё squid
поставить.
</PRE>
</BLOCKQUOTE>
Смысл nginx'а для меня, возможность более быстрого обслуживания запросов к динамическим страницам. Благодаря буферизации ответа backend'а на диск или в буферы nginx'а с backend'а снимается необходимость простоя в ожидании пока клиент заберет данные.<BR>
<BR>
Но проблема, моя лично, заключается в том, что я не всегда могу определить где будет статика а где динамика.<BR>
Еще раз говорю, знай я что по конкретному location'у будут многогиговые статические файлы, апач бы никогда не получил туда запрос.<BR>
<BR>
<B>А вот теперь по теме:</B><BR>
<B>Я лишь хочу выяснить и понять логику работы nginx модуля proxy при облуживании запроса, у которого присутствует заголовок content-range, чтобы иметь возможность его правильно настроить. О чем я собственно и спросил в первом сообщении.</B>
<BLOCKQUOTE TYPE=CITE>
<PRE>
> Если бы у меня была возможность разделить зоны вхостов на статические и
> динамические я бы просто статику прописал в отдачу на прямую nginx'ом и эту
> тему не поднимал бы.
>
> Меня больше интересыет логика работы nginx'а при проксировании запроса с
> установленным content-range. Зная ее можно будет планировать обход подобных
> проблемных мест.
</PRE>
</BLOCKQUOTE>
<BR>
</BODY>
</HTML>