В Втр, 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. Зная ее можно будет планировать обход подобных
> проблемных мест.
