Re: proxy_cache и range запросы

[Danila Shtan]

Хочу вернуться к вопросу о патче из
http://forum.nginx.org/read.php?2,225815,225826#msg-225826
Мы его используем в production, на двух нодах с 150-200 rps на ноду, все
едет с proxy_cache (точнее — с uwsgi_cache).
Больше двух недель, полет стабильный, нареканий нет.

Собрано вот так:
[501 12:53:23]: # nginx -V
nginx version: nginx/1.2.6
TLS SNI support enabled
configure arguments: --prefix=/usr/share/nginx
--conf-path=/etc/nginx/nginx.conf --error-log-path=/var/log/nginx/error.log
--http-client-body-temp-path=/var/lib/nginx/body
--http-fastcgi-temp-path=/var/lib/nginx/fastcgi
--http-log-path=/var/log/nginx/access.log
--http-proxy-temp-path=/var/lib/nginx/proxy
--http-scgi-temp-path=/var/lib/nginx/scgi
--http-uwsgi-temp-path=/var/lib/nginx/uwsgi
--lock-path=/var/lock/nginx.lock --pid-path=/var/run/nginx.pid
--with-pcre-jit --with-debug --with-file-aio --with-http_addition_module
--with-http_dav_module --with-http_geoip_module
--with-http_gzip_static_module --with-http_image_filter_module
--with-http_realip_module --with-http_secure_link_module
--with-http_stub_status_module --with-http_ssl_module
--with-http_sub_module --with-http_xslt_module --with-ipv6
--with-sha1=/usr/include/openssl --with-md5=/usr/include/openssl
--with-mail --with-mail_ssl_module
--add-module=/opt/nginx-1.2.6/debian/modules/nginx-auth-pam
--add-module=/opt/nginx-1.2.6/debian/modules/nginx-echo
--add-module=/opt/nginx-1.2.6/debian/modules/nginx-upstream-fair
--add-module=/opt/nginx-1.2.6/debian/modules/nginx-dav-ext-module
--add-module=/opt/nginx-1.2.6/debian/modules/nginx-syslog
--add-module=/opt/nginx-1.2.6/debian/modules/nginx-cache-purge
--add-module=/opt/nginx-1.2.6/debian/modules/nginx-pinba
--add-module=/opt/nginx-1.2.6/debian/modules/nginx-http-substitution-filter
--add-module=/root/nginx-pkg/mod_zip-1.1.6
--add-module=/root/nginx-pkg/nginx-statsd --with-http_image_filter_module

Д.

2013/1/22 Danila Shtan <danila at shtan.ru>

> Приветствую.
>
>
> 2013/1/22 Maxim Dounin <mdounin at mdounin.ru>
>
>> Hello!
>>
>> On Tue, Jan 22, 2013 at 02:38:53AM +0600, Danila Shtan wrote:
>>
>> > Приветствую.
>> >
>> > 1) Для proxy_cache и range есть небольшой патч от Maxim Dounin (
>> > http://forum.nginx.org/read.php?2,225815,225826#msg-225826) который
>> > насколько я понимаю не внесен в основную ветку разработки (из-за проблем
>> > при max_ranges >1), но в случае применения его решает проблему получения
>> > 200 OK при первом запросе к бэкенду и заполнении кэша. Может быть имеет
>> > смысл включить такое поведение по умолчанию при max_ranges 1;? Многие
>> > современные браузеры в части воспроизведения HTML5 видео сурово
>> завязаны на
>> > 206 и правильный Range в ответ на свои запросы, мне кажется, что было бы
>> > неплохо учесть существующие реалии.
>>
>> Может быть.
>>
>> Опыт использования патча в production имеется?  Если да - хотелось
>> бы услышать отзывы.
>>
>
> По вышепомянутой ссылке человек, кажется, доволен.
> Мы свою сборку с патчем и 3rd-party модулями выкатываем завтра — через
> неделю буду готов поделиться впечатлениями.
>
>
>> > 2) nginx ни за что не отдаст 206 ответ при запросе c Range к
>> > закэшированному файлу, если в оригинальном ответе бэкенда не было
>> заголовка
>> > Accept-Ranges. Поведение мягко говоря не очевидное, стоило мне
>> нескольких
>> > часов попыток понять, что происходит. RFC говорит, что заголовок
>> совершенно
>> > опциональный, более того, если nginx уже получил полное тело файла,
>> имеет
>> > Content-Length ответа и пр. — еще более непонятно, что мешает ему
>> отдавать
>> > ожидаемые клиентом 206.
>>
>> В самом nginx'е допустимость byte-range-запросов однозначно
>> приводит к появлению заголовка Accept-Ranges (а отсутствие оной
>> поддержки - приводит к его отсутствию), и AFAIK в большинстве
>> других серверов так же.  Такое поведение - позволяет максимально
>> полно дублировать поведение исходного сервера, допуская range'и
>> только там, где бекенд их поддерживает.
>>
>
> Там где бэкенд их не поддерживает ему, вероятно, стоит сказать
> Accept-Ranges: none
> Проблема в том, что эта особенность сервера не описана вообще нигде. :)
>
> Наверное, теперь, когда есть директива max_ranges, и не желающие
>> поддержки range'ей могут от неё отказаться явно, это поведение
>> стоит пересмотреть.
>>
>
> По-моему это хорошая идея.
>
> Д.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.nginx.org/pipermail/nginx-ru/attachments/20130208/41d2adcd/attachment-0001.html>