ПРОЕКТЫ 


  АРХИВ 


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


  • To: nginx-ru@xxxxxxxxx
  • Subject: Re: proxy vs content-range
  • From: Sergey Shepelev <temotor@xxxxxxxxx>
  • Date: Tue, 22 Dec 2009 20:45:38 +0300
  • Dkim-signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:content-type :content-transfer-encoding; bh=O5GQj6XrHrrQUW0FKDyhUbIm25QWXF5tI+uI2TG99eY=; b=vLO3vrHozvt0s9B6gIXUJdWPxrImuAfADNpSpWiSfI/1/dsufi9njjo3brJmnn26nw vi+EZ+YqBLf7M978/zhUi28oSNtR4MtS7+4ASjvilGDLPJFw7hvXPn3zpWHvaYkeT9PX bviezRomQpqS+Xrezm7iD11KG2Oao2/OSHWT8=
  • Domainkey-signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type:content-transfer-encoding; b=WoF7Cx89j/ozp3bAFspFYbpHlf3ObpWSXvjMIr3HziP+TmBlflWxMz5cG3/y6bThzb AIhtO5bSxRUXAVqZo0Ncp8ZaYbBs4mQFF6pEFLgSxPMnC8PO5hTFCl3QsXnIfCM94EQc j4V+CIoy3LXxdooejr0SAAp3XjRsjU8ftNsT4=
  • In-reply-to: <1261502892.9546.38.camel@localhost>
  • References: <1261496323.9546.31.camel@localhost> <2d8fb9950912220812n634c6bf2p33b8be06abb15abc@xxxxxxxxxxxxxx> <1261502892.9546.38.camel@localhost>

2009/12/22 Bogun Dmitriy <vugluskr@xxxxxxxxxxxxxxx>:
> В Втр, 22/12/2009 в 19:12 +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 поток,
следовательно, может принять запросы от тысячи клиентов одновременно.
Ещё мне лично синтаксис конфига нравится больше, чем у других веб
серверов.

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

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

> Если бы у меня была возможность разделить зоны вхостов на статические и
> динамические я бы просто статику прописал в отдачу на прямую nginx'ом и эту
> тему не поднимал бы.
>
> Меня больше интересыет логика работы nginx'а при проксировании запроса с
> установленным content-range. Зная ее можно будет планировать обход подобных
> проблемных мест.
> _______________________________________________
> nginx-ru mailing list
> nginx-ru@xxxxxxxxx
> http://nginx.org/mailman/listinfo/nginx-ru
>
>
_______________________________________________
nginx-ru mailing list
nginx-ru@xxxxxxxxx
http://nginx.org/mailman/listinfo/nginx-ru


 




Copyright © Lexa Software, 1996-2009.