<div dir="ltr">Хочу вернуться к вопросу о патче из <a href="http://forum.nginx.org/read.php?2,225815,225826#msg-225826" target="_blank">http://forum.nginx.org/read.php?2,225815,225826#msg-225826</a><div>Мы его используем в production, на двух нодах с 150-200 rps на ноду, все едет с proxy_cache (точнее — с uwsgi_cache).</div>
<div>Больше двух недель, полет стабильный, нареканий нет.</div><div><br></div><div>Собрано вот так:</div><div><div>[501 12:53:23]: # nginx -V</div><div>nginx version: nginx/1.2.6</div><div>TLS SNI support enabled</div><div>
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</div>
<div class="gmail_extra"><br></div><div class="gmail_extra" style>Д.</div><div class="gmail_extra"><br><div class="gmail_quote">2013/1/22 Danila Shtan <span dir="ltr"><<a href="mailto:danila@shtan.ru" target="_blank">danila@shtan.ru</a>></span><br>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div dir="ltr">Приветствую.<div class="gmail_extra"><br><br>
<div class="gmail_quote"><div class="im">2013/1/22 Maxim Dounin <span dir="ltr"><<a href="mailto:mdounin@mdounin.ru" target="_blank">mdounin@mdounin.ru</a>></span><br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">

Hello!<br>
<div><br>
On Tue, Jan 22, 2013 at 02:38:53AM +0600, Danila Shtan wrote:<br>
<br>
> Приветствую.<br>
><br>
> 1) Для proxy_cache и range есть небольшой патч от Maxim Dounin (<br>
> <a href="http://forum.nginx.org/read.php?2,225815,225826#msg-225826" target="_blank">http://forum.nginx.org/read.php?2,225815,225826#msg-225826</a>) который<br>
> насколько я понимаю не внесен в основную ветку разработки (из-за проблем<br>
> при max_ranges >1), но в случае применения его решает проблему получения<br>
> 200 OK при первом запросе к бэкенду и заполнении кэша. Может быть имеет<br>
> смысл включить такое поведение по умолчанию при max_ranges 1;? Многие<br>
> современные браузеры в части воспроизведения HTML5 видео сурово завязаны на<br>
> 206 и правильный Range в ответ на свои запросы, мне кажется, что было бы<br>
> неплохо учесть существующие реалии.<br>
<br>
</div>Может быть.<br>
<br>
Опыт использования патча в production имеется?  Если да - хотелось<br>
бы услышать отзывы.<br></blockquote><div><br></div></div><div>По вышепомянутой ссылке человек, кажется, доволен.</div><div>Мы свою сборку с патчем и 3rd-party модулями выкатываем завтра — через неделю буду готов поделиться впечатлениями.</div>
<div class="im">
<div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div>
> 2) nginx ни за что не отдаст 206 ответ при запросе c Range к<br>
> закэшированному файлу, если в оригинальном ответе бэкенда не было заголовка<br>
> Accept-Ranges. Поведение мягко говоря не очевидное, стоило мне нескольких<br>
> часов попыток понять, что происходит. RFC говорит, что заголовок совершенно<br>
> опциональный, более того, если nginx уже получил полное тело файла, имеет<br>
> Content-Length ответа и пр. — еще более непонятно, что мешает ему отдавать<br>
> ожидаемые клиентом 206.<br>
<br>
</div>В самом nginx'е допустимость byte-range-запросов однозначно<br>
приводит к появлению заголовка Accept-Ranges (а отсутствие оной<br>
поддержки - приводит к его отсутствию), и AFAIK в большинстве<br>
других серверов так же.  Такое поведение - позволяет максимально<br>
полно дублировать поведение исходного сервера, допуская range'и<br>
только там, где бекенд их поддерживает.<br></blockquote><div><br></div></div><div>Там где бэкенд их не поддерживает ему, вероятно, стоит сказать Accept-Ranges: none</div><div>Проблема в том, что эта особенность сервера не описана вообще нигде. :)</div>
<div class="im">
<div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">Наверное, теперь, когда есть директива max_ranges, и не желающие<br>

поддержки range'ей могут от неё отказаться явно, это поведение<br>
стоит пересмотреть.<br></blockquote><div><br></div></div><div>По-моему это хорошая идея.</div><div><br></div><div>Д.</div></div></div></div>
</blockquote></div><br></div></div></div>