Re: slice module и proxy_cache_min_uses больше единицы.
25 февраля 2016 г., 21:28 пользователь Roman Arutyunyan написал: > > Попробуйте патч в аттаче. > > Роман, спасибо! Теперь все работает как задумано. > > И чтоб 2 раза не вставать, спрошу, отчего может возникать проблема с > > переполнением диска? > > Диск 220G, max_cache опустил до 190G, а на деле диск забивается под > > завязку, причем именно кешем (proxy_cache_min_uses 1, slice 10m, 10-20 > rps). > > В temp в этот момент не более 20 временных файлов размером ~ 10 > мегабайт. В > > кеше все элементы <= 10 мегабайт. > > Незакрытых удаленных файлов на диске нет. > > В error log куча сообщений c No space left on device. > > Может быть такое, что кеш растет так быстро, что nginx не успевает его > очищать. > > Еще одна причина - рестарт воркеров. Если по какой-либо причине это > происходит > (например, из-за нестабильных 3rd-party модулей), то кеш может остаться в > неконсистентном состоянии, что может приводить к описанной вами проблеме. > > Насколько часто это у вас это происходит? > > В том-то и дело, что воркеры не падают и сборка без сторонних модулей. Глядя на strace процесса cache manager, видно, что он что-то удаляет, но каждый раз недостаточно. Суммарный размер каталогов 0-f балансирует около значения размера диска (220G) и до указанных 190G даже близко не опускается. При этом '(deleted)' файлов на диске нет и в temp файлов суммарно мегабайт на 300. Ближе к вечеру станет ясно, повториться ли эта проблема с proxy_cache_min_uses 10. Пока что очевидно, что write-IO сократилось на порядок. Авось ssd протянут подольше, за что вам еще раз спасибо. ___ nginx-ru mailing list nginx-ru@nginx.org http://mailman.nginx.org/mailman/listinfo/nginx-ru
Re: nginx отъедает все процессорное время
26 февраля 2016 г., 2:40 пользователь Alex Domoradov написал: > > Не нужно ничего устанавливать. > > nginx-debug уже установлен, он ставится вместе с основным пакетом, его > нужно только запустить. > > странно, как минимум на ubuntu 12.04 LTS и CentOS 6 для nginx-1.8 это не > справедливо. > > # rpm -qa | grep nginx > nginx-1.8.1-1.el6.ngx.x86_64 > > # rpm -ql nginx | grep debug > > или это относится только к ветке 1.9? > Речь не о пакете, а о бинаре: $ which nginx-debug /usr/sbin/nginx-debug > > 2016-02-25 22:10 GMT+02:00 Валентин Бартенев : > >> On Thursday 25 February 2016 15:05:42 mikhal123 wrote: >> > Валентин Бартенев Wrote: >> > > Не нужно ничего устанавливать. >> > > nginx-debug уже установлен, он ставится вместе с основным пакетом, >> > > его нужно только запустить. >> > >> > что-то я не понимаю... >> > >> > aptitude show nginx-debug >> > Пакет: nginx-debug >> > Новый: да >> > Состояние: не установлен >> > Версия: 1.9.7-1~jessie >> > Приоритет: дополнительный >> > Раздел: debug >> > Сопровождающий: Sergey Budnevitch >> > Архитектура: amd64 >> > Размер в распакованном виде: 7 951 k >> > Зависимости: libc6 (>= 2.14), libpcre3 (>= 1:8.35), libssl1.0.0 (>= >> 1.0.1), >> > zlib1g (>= 1:1.1.4), nginx (= 1.9.7-1~jessie) >> > Описание: debug version of nginx >> > Not stripped version of nginx built with the debugging log support. >> > Сайт: http://nginx.org >> > >> > >> > помимо этого, вот тут вот >> > http://nginx.org/packages/mainline/debian/pool/nginx/n/nginx/ >> > вроде как видно что версия для 1.9.7 является крайней? >> > nginx-debug_1.9.7-1~wheezy_i386.deb17-Nov-2015 15:55 >> > 3936370 >> > >> [..] >> >> Я имел в виду не пакет, а исполняемый файл. Основной пакет nginx на самом >> деле устанавливает два бинарника - nginx и nginx-debug, где последний >> является >> той же версией, но собранный с --with-debug. >> >> $ nginx-debug -V >> >> -- >> Валентин Бартенев >> ___ >> nginx-ru mailing list >> nginx-ru@nginx.org >> http://mailman.nginx.org/mailman/listinfo/nginx-ru >> > > > ___ > nginx-ru mailing list > nginx-ru@nginx.org > http://mailman.nginx.org/mailman/listinfo/nginx-ru > ___ nginx-ru mailing list nginx-ru@nginx.org http://mailman.nginx.org/mailman/listinfo/nginx-ru
Re: модуль на заказ
Сасибо за советы, но от использования php, а точнее hiphop под эту задачу ушел пару лет назад. Слишком тяжелый комбаин для такой простой работы. А модуль уже починил, там проблемы были с ноль-терминированными строками. Короче вопрос снят :) ~~~ wbr, Alexander Uskov - Исходное сообщение - > От: "Konstantin Baryshnikov" > Кому: nginx-ru@nginx.org > Отправленные: Пятница, 26 Февраль 2016 г 10:51:19 > Тема: Re: модуль на заказ > > > > В принципе практически все делается с использованием основной > > логики nginx, хидерс и ssi модулей, но проблемма > > именно с генерением php uniqid. Можно, конечно попытаться перейти > > на тот-же userid модуль, но тогда придется > > много что менять в бакэнде, который дальше будет это обрабатывать, > > чего бы сильно не хотелось. > > К уже озвученному совету с X-Accel-Redirect добавлю, что для его > отдачи можно использовать сам php в неблокирующем режиме - например, > с помощью http://reactphp.org/, будет буквально 10 строк кода, и > вполне вменяемо по потреблению ресурсов. > ___ > nginx-ru mailing list > nginx-ru@nginx.org > http://mailman.nginx.org/mailman/listinfo/nginx-ru ___ nginx-ru mailing list nginx-ru@nginx.org http://mailman.nginx.org/mailman/listinfo/nginx-ru
Re: модуль на заказ
> В принципе практически все делается с использованием основной логики nginx, > хидерс и ssi модулей, но проблемма > именно с генерением php uniqid. Можно, конечно попытаться перейти на тот-же > userid модуль, но тогда придется > много что менять в бакэнде, который дальше будет это обрабатывать, чего бы > сильно не хотелось. К уже озвученному совету с X-Accel-Redirect добавлю, что для его отдачи можно использовать сам php в неблокирующем режиме - например, с помощью http://reactphp.org/, будет буквально 10 строк кода, и вполне вменяемо по потреблению ресурсов. ___ nginx-ru mailing list nginx-ru@nginx.org http://mailman.nginx.org/mailman/listinfo/nginx-ru
Re: nginx отъедает все процессорное время
> Не нужно ничего устанавливать. > nginx-debug уже установлен, он ставится вместе с основным пакетом, его нужно только запустить. странно, как минимум на ubuntu 12.04 LTS и CentOS 6 для nginx-1.8 это не справедливо. # rpm -qa | grep nginx nginx-1.8.1-1.el6.ngx.x86_64 # rpm -ql nginx | grep debug или это относится только к ветке 1.9? 2016-02-25 22:10 GMT+02:00 Валентин Бартенев : > On Thursday 25 February 2016 15:05:42 mikhal123 wrote: > > Валентин Бартенев Wrote: > > > Не нужно ничего устанавливать. > > > nginx-debug уже установлен, он ставится вместе с основным пакетом, > > > его нужно только запустить. > > > > что-то я не понимаю... > > > > aptitude show nginx-debug > > Пакет: nginx-debug > > Новый: да > > Состояние: не установлен > > Версия: 1.9.7-1~jessie > > Приоритет: дополнительный > > Раздел: debug > > Сопровождающий: Sergey Budnevitch > > Архитектура: amd64 > > Размер в распакованном виде: 7 951 k > > Зависимости: libc6 (>= 2.14), libpcre3 (>= 1:8.35), libssl1.0.0 (>= > 1.0.1), > > zlib1g (>= 1:1.1.4), nginx (= 1.9.7-1~jessie) > > Описание: debug version of nginx > > Not stripped version of nginx built with the debugging log support. > > Сайт: http://nginx.org > > > > > > помимо этого, вот тут вот > > http://nginx.org/packages/mainline/debian/pool/nginx/n/nginx/ > > вроде как видно что версия для 1.9.7 является крайней? > > nginx-debug_1.9.7-1~wheezy_i386.deb17-Nov-2015 15:55 > > 3936370 > > > [..] > > Я имел в виду не пакет, а исполняемый файл. Основной пакет nginx на самом > деле устанавливает два бинарника - nginx и nginx-debug, где последний > является > той же версией, но собранный с --with-debug. > > $ nginx-debug -V > > -- > Валентин Бартенев > ___ > nginx-ru mailing list > nginx-ru@nginx.org > http://mailman.nginx.org/mailman/listinfo/nginx-ru > ___ nginx-ru mailing list nginx-ru@nginx.org http://mailman.nginx.org/mailman/listinfo/nginx-ru
Re: nginx отъедает все процессорное время
On Thursday 25 February 2016 15:05:42 mikhal123 wrote: > Валентин Бартенев Wrote: > > Не нужно ничего устанавливать. > > nginx-debug уже установлен, он ставится вместе с основным пакетом, > > его нужно только запустить. > > что-то я не понимаю... > > aptitude show nginx-debug > Пакет: nginx-debug > Новый: да > Состояние: не установлен > Версия: 1.9.7-1~jessie > Приоритет: дополнительный > Раздел: debug > Сопровождающий: Sergey Budnevitch > Архитектура: amd64 > Размер в распакованном виде: 7 951 k > Зависимости: libc6 (>= 2.14), libpcre3 (>= 1:8.35), libssl1.0.0 (>= 1.0.1), > zlib1g (>= 1:1.1.4), nginx (= 1.9.7-1~jessie) > Описание: debug version of nginx > Not stripped version of nginx built with the debugging log support. > Сайт: http://nginx.org > > > помимо этого, вот тут вот > http://nginx.org/packages/mainline/debian/pool/nginx/n/nginx/ > вроде как видно что версия для 1.9.7 является крайней? > nginx-debug_1.9.7-1~wheezy_i386.deb17-Nov-2015 15:55 > 3936370 > [..] Я имел в виду не пакет, а исполняемый файл. Основной пакет nginx на самом деле устанавливает два бинарника - nginx и nginx-debug, где последний является той же версией, но собранный с --with-debug. $ nginx-debug -V -- Валентин Бартенев ___ nginx-ru mailing list nginx-ru@nginx.org http://mailman.nginx.org/mailman/listinfo/nginx-ru
Re: nginx отъедает все процессорное время
Валентин Бартенев Wrote: > Не нужно ничего устанавливать. > nginx-debug уже установлен, он ставится вместе с основным пакетом, > его нужно только запустить. что-то я не понимаю... aptitude show nginx-debug Пакет: nginx-debug Новый: да Состояние: не установлен Версия: 1.9.7-1~jessie Приоритет: дополнительный Раздел: debug Сопровождающий: Sergey Budnevitch Архитектура: amd64 Размер в распакованном виде: 7 951 k Зависимости: libc6 (>= 2.14), libpcre3 (>= 1:8.35), libssl1.0.0 (>= 1.0.1), zlib1g (>= 1:1.1.4), nginx (= 1.9.7-1~jessie) Описание: debug version of nginx Not stripped version of nginx built with the debugging log support. Сайт: http://nginx.org помимо этого, вот тут вот http://nginx.org/packages/mainline/debian/pool/nginx/n/nginx/ вроде как видно что версия для 1.9.7 является крайней? nginx-debug_1.9.7-1~wheezy_i386.deb17-Nov-2015 15:55 3936370 Posted at Nginx Forum: https://forum.nginx.org/read.php?21,264701,264854#msg-264854 ___ nginx-ru mailing list nginx-ru@nginx.org http://mailman.nginx.org/mailman/listinfo/nginx-ru
Re: nginx отъедает все процессорное время
On Thursday 25 February 2016 14:52:15 mikhal123 wrote: > ALex_hha Wrote: > --- > > > > сам его я его точно не соберу как нужно, и как тут быть? > > > > А зачем его собирать? За вас уже все собрали > > # aptitude install nginx-debug > > ну как-то так... > > aptitude install nginx-debug > Следующие НОВЫЕ пакеты будут установлены: > nginx-debug{b} > 0 пакетов обновлено, 1 установлено новых, 0 пакетов отмечено для удаления, и > 0 пакетов не обновлено. > Необходимо получить 1 630 kB архивов. После распаковки 7 951 kB будет > занято. > Следующие пакеты имеют неудовлетворённые зависимости: > nginx-debug : Зависит: nginx (= 1.9.7-1~jessie) но установлен > 1.9.12-1~jessie > Следующие действия разрешат зависимости: > > Сохранить для следующих пакетов их текущие версии: > 1) nginx-debug [Не установлен] > [..] Не нужно ничего устанавливать. nginx-debug уже установлен, он ставится вместе с основным пакетом, его нужно только запустить. -- Валентин Бартенев ___ nginx-ru mailing list nginx-ru@nginx.org http://mailman.nginx.org/mailman/listinfo/nginx-ru
Re: nginx отъедает все процессорное время
ALex_hha Wrote: --- > > сам его я его точно не соберу как нужно, и как тут быть? > А зачем его собирать? За вас уже все собрали > # aptitude install nginx-debug ну как-то так... aptitude install nginx-debug Следующие НОВЫЕ пакеты будут установлены: nginx-debug{b} 0 пакетов обновлено, 1 установлено новых, 0 пакетов отмечено для удаления, и 0 пакетов не обновлено. Необходимо получить 1 630 kB архивов. После распаковки 7 951 kB будет занято. Следующие пакеты имеют неудовлетворённые зависимости: nginx-debug : Зависит: nginx (= 1.9.7-1~jessie) но установлен 1.9.12-1~jessie Следующие действия разрешат зависимости: Сохранить для следующих пакетов их текущие версии: 1) nginx-debug [Не установлен] Posted at Nginx Forum: https://forum.nginx.org/read.php?21,264701,264852#msg-264852 ___ nginx-ru mailing list nginx-ru@nginx.org http://mailman.nginx.org/mailman/listinfo/nginx-ru
Re: slice module и proxy_cache_min_uses больше единицы.
On Thu, Feb 25, 2016 at 06:44:03PM +0300, Vadim Lazovskiy wrote: > 25 февраля 2016 г., 16:53 пользователь Roman Arutyunyan > написал: > > > > > > Маловат фрагмент. Хотелось бы посмотреть на весь запрос и подзапросы. > > > > > Сразу прошу прощения за размер логов. > > http://disk.karelia.pro/833rexx/ > > Два лога: > 1. с proxy_cache_min_uses 1. Работает, как задумывалось. > Запрос на перемотку можно найти по диапазону 498197221-1279019570. > > 2. с proxy_cache_min_uses 50. Ломается перемотка из-за игнорирования Range > (или учета If-Range, кто его разберет). > Запрос на пеермотку можно найти по диапазону 467829492-1279019570. Попробуйте патч в аттаче. > И чтоб 2 раза не вставать, спрошу, отчего может возникать проблема с > переполнением диска? > Диск 220G, max_cache опустил до 190G, а на деле диск забивается под > завязку, причем именно кешем (proxy_cache_min_uses 1, slice 10m, 10-20 rps). > В temp в этот момент не более 20 временных файлов размером ~ 10 мегабайт. В > кеше все элементы <= 10 мегабайт. > Незакрытых удаленных файлов на диске нет. > В error log куча сообщений c No space left on device. Может быть такое, что кеш растет так быстро, что nginx не успевает его очищать. Еще одна причина - рестарт воркеров. Если по какой-либо причине это происходит (например, из-за нестабильных 3rd-party модулей), то кеш может остаться в неконсистентном состоянии, что может приводить к описанной вами проблеме. Насколько часто это у вас это происходит? -- Roman Arutyunyan # HG changeset patch # User Roman Arutyunyan # Date 1456424237 -10800 # Thu Feb 25 21:17:17 2016 +0300 # Node ID 93266a5c3377443acc1091fd8b2f3553e19bfa09 # Parent 6812ca9a800247d2428f487d9b4938a2b499b7d8 [mq]: upstream-lmt diff -r 6812ca9a8002 -r 93266a5c3377 src/http/ngx_http_upstream.c --- a/src/http/ngx_http_upstream.c Tue Feb 16 17:49:14 2016 +0300 +++ b/src/http/ngx_http_upstream.c Thu Feb 25 21:17:17 2016 +0300 @@ -4146,15 +4146,8 @@ ngx_http_upstream_process_last_modified( u = r->upstream; u->headers_in.last_modified = h; - -#if (NGX_HTTP_CACHE) - -if (u->cacheable) { -u->headers_in.last_modified_time = ngx_parse_http_time(h->value.data, - h->value.len); -} - -#endif +u->headers_in.last_modified_time = ngx_parse_http_time(h->value.data, + h->value.len); return NGX_OK; } @@ -4651,15 +4644,8 @@ ngx_http_upstream_copy_last_modified(ngx *ho = *h; r->headers_out.last_modified = ho; - -#if (NGX_HTTP_CACHE) - -if (r->upstream->cacheable) { -r->headers_out.last_modified_time = +r->headers_out.last_modified_time = r->upstream->headers_in.last_modified_time; -} - -#endif return NGX_OK; } ___ nginx-ru mailing list nginx-ru@nginx.org http://mailman.nginx.org/mailman/listinfo/nginx-ru
Re: Nginx не пропускает от proxy длинный Content-Disposition
Да, действительно, проблема до Nginx. Ошибка вышла. Прошу прощения за ошибочную тревогу. Posted at Nginx Forum: https://forum.nginx.org/read.php?21,264758,264847#msg-264847 ___ nginx-ru mailing list nginx-ru@nginx.org http://mailman.nginx.org/mailman/listinfo/nginx-ru
Re: zero size buf in output при proxy cache
Hello! On Thu, Feb 25, 2016 at 06:19:04PM +0300, Иван wrote: > Можем ли мы еще что-то сделать для решения этой проблемы? Да, в идеале - тесты и патч, её исправляющий. Также имеет смысл: - описать проблему на trac.nginx.org; - периодически напоминать, что проблема всё ещё вас беспокоит и по прежнему проявляется на актуальных версиях. В почте у меня соответствующее письмо отмечено, но вряд ли я доберусь до "посмотреть это подробнее" в ближайшее время. -- Maxim Dounin http://nginx.org/ ___ nginx-ru mailing list nginx-ru@nginx.org http://mailman.nginx.org/mailman/listinfo/nginx-ru
Re: Вопрос про proxy store
On Thu, Feb 25, 2016 at 10:17:20AM -0500, vitcool wrote: > А поженить proxy_store и proxy_cache нельзя? :) > например: если нет в proxy_cache, то искать в alias у proxy_store, и если > там нет то тогда идти к proxy_pass бекенду на поклон? Можно, например так: - server { listen 80; location / { proxy_passhttp://127.0.0.1:8080; proxy_cache static; proxy_cache_valid 200 1d; } } server { listen 127.0.0.1:8080; location / { root /data/www; error_page 404 = /fetch$uri; } location /fetch/ { internal; proxy_pass http://backend/; proxy_storeon; proxy_store_access user:rw group:rw all:r; proxy_temp_path/data/temp; alias /data/www/; } - Конфигурацию не проверял, но идея, надеюсь, понятна. > Наверное выглядит немного бредово, но это отчасти решает проблему бекапа статики которая изначально появляется на бекенде > > Posted at Nginx Forum: > https://forum.nginx.org/read.php?21,264801,264830#msg-264830 > > ___ > nginx-ru mailing list > nginx-ru@nginx.org > http://mailman.nginx.org/mailman/listinfo/nginx-ru -- Cheers, Oleg A. Mamontov mailto: o...@mamontov.net skype: lonerr11 cell: +7 (903) 798-1352 ___ nginx-ru mailing list nginx-ru@nginx.org http://mailman.nginx.org/mailman/listinfo/nginx-ru
Re: slice module + thread pools
2016-02-25 19:20 GMT+03:00 Maxim Dounin : > Патч: > > # HG changeset patch > # User Maxim Dounin > # Date 1456417157 -10800 > # Thu Feb 25 19:19:17 2016 +0300 > # Node ID 06da00f231e74bbb8dbb55fd6abd88ca8b207917 > # Parent 463609ba52b07e8e669d83ca7ca7fa754ae5355a > Fixed sendfile in threads when used with subrequests. > > If sendfile in threads where used, it was possible that multiple > subrequests will trigger multiple ngx_linux_sendfile_thread() calls, > as operations are only serialized in output chain based on r->aio, > that is, on subrequest level. > > This resulted in "task #N already active" alerts, in particular, when > running proxy_store.t with "aio threads; sendfile on;". > > Fix is to tolerate duplicate calls, with an additional safety check > that the file is the same as previously used. > > diff --git a/src/os/unix/ngx_linux_sendfile_chain.c > b/src/os/unix/ngx_linux_sendfile_chain.c > --- a/src/os/unix/ngx_linux_sendfile_chain.c > +++ b/src/os/unix/ngx_linux_sendfile_chain.c > @@ -354,6 +354,18 @@ ngx_linux_sendfile_thread(ngx_connection > return (ctx->sent == ctx->size) ? NGX_DONE : NGX_AGAIN; > } > > +if (task->event.active && ctx->file == file) { > +/* > + * tolerate duplicate calls with the same file; > + * it can happen due to subrequests, as r->aio only serializes > + * operations within a single subrequest > + */ > + > +*sent = 0; > + > +return NGX_OK; > +} > + > ctx->file = file; > ctx->socket = c->fd; > ctx->size = size; > > Максим, спасибо. На первый взгляд патч работает. Завтра попробуем под нагрузкой. P.S.: может показаться, что я не умею пользоваться почтой. Похоже, это действительно так. Прошу меня извинить ;) -- WBR, Vadim Lazovskiy ___ nginx-ru mailing list nginx-ru@nginx.org http://mailman.nginx.org/mailman/listinfo/nginx-ru
Re: slice module + thread pools
2016-02-25 19:20 GMT+03:00 Maxim Dounin : > > > Это выглядит как проблема при aio threads + sendfile + подзапросы. > Workaround - выключить что-нибудь из списка. Just for the record, > воспроизводится с помощью тестов как-то так: > > TEST_NGINX_GLOBALS_HTTP="aio threads; sendfile on;" prove proxy_store.t > > Патч: > > # HG changeset patch > # User Maxim Dounin > # Date 1456417157 -10800 > # Thu Feb 25 19:19:17 2016 +0300 > # Node ID 06da00f231e74bbb8dbb55fd6abd88ca8b207917 > # Parent 463609ba52b07e8e669d83ca7ca7fa754ae5355a > Fixed sendfile in threads when used with subrequests. > > If sendfile in threads where used, it was possible that multiple > subrequests will trigger multiple ngx_linux_sendfile_thread() calls, > as operations are only serialized in output chain based on r->aio, > that is, on subrequest level. > > This resulted in "task #N already active" alerts, in particular, when > running proxy_store.t with "aio threads; sendfile on;". > > Fix is to tolerate duplicate calls, with an additional safety check > that the file is the same as previously used. > > diff --git a/src/os/unix/ngx_linux_sendfile_chain.c > b/src/os/unix/ngx_linux_sendfile_chain.c > --- a/src/os/unix/ngx_linux_sendfile_chain.c > +++ b/src/os/unix/ngx_linux_sendfile_chain.c > @@ -354,6 +354,18 @@ ngx_linux_sendfile_thread(ngx_connection > return (ctx->sent == ctx->size) ? NGX_DONE : NGX_AGAIN; > } > > +if (task->event.active && ctx->file == file) { > +/* > + * tolerate duplicate calls with the same file; > + * it can happen due to subrequests, as r->aio only serializes > + * operations within a single subrequest > + */ > + > +*sent = 0; > + > +return NGX_OK; > +} > + > ctx->file = file; > ctx->socket = c->fd; > ctx->size = size; > -- WBR, Vadim Lazovskiy ___ nginx-ru mailing list nginx-ru@nginx.org http://mailman.nginx.org/mailman/listinfo/nginx-ru
Re: Nginx не пропускает от proxy длинный Content-Disposition
On Thursday 25 February 2016 11:16:38 ErmakovIE wrote: > Здравствуйте! > > Прошу прощения за недостаточно точный вопрос. Ожидал, что просто уперся в > какую-то настройку. > > Версия 1.8.0, Linux (Ubuntu). > > Конфиг: > location /_download { > alias /var/fnc_storage; > internal; > } > > location / { > proxy_redirect off; > proxy_set_header X-Real-IP $remote_addr; > proxy_set_header Host localhost:8088; > proxy_set_header X-Forwarded-For $remote_addr; > proxy_pass http://localhost:8088; > } > > Приложение генерирует заголовки: > > X-Accel-Redirect: /_download/12345 > > Content-Disposition: attachment; > filename="Odrin_Metod_morfologicheskogo_analiza_texnicheskix_sistem_k.doc"; > filename*=UTF-8''%D0%9E%D0%B4%D1%80%D0%B8%D0%BD_%D0%9C%D0%B5%D1%82%D0%BE%D0%B4%20%D0%BC%D0%BE%D1%80%D1%84%D0%BE%D0%BB%D0%BE%D0%B3%D0%B8%D1%87%D0%B5%D1%81%D0%BA%D0%BE%D0%B3%D0%BE%20%D0%B0%D0%BD%D0%B0%D0%BB%D0%B8%D0%B7%D0%B0%20%D1%82%D0%B5%D1%85%D0%BD%D0%B8%D1%87%D0%B5%D1%81%D0%BA%D0%B8%D1%85%20%D1%81%D0%B8%D1%81%D1%82%D0%B5%D0%BC_k.doc > > (в соответствии с RFC5987). > > Когда имя файла небольшое - и в кодированном виде длина заголовка меньше > примерно 256 (если не ошибся, то почему-то граница 258, а не 256), то всё > проходит верно - Nginx отдаёт файл по пути _download и пропускает заголовок > Content-Disposition, сформированный приложением. > > Но вот для приведенного примера заголовка, когда имя файла длинное, > Nginx вместо Content-Disposition, полученного от приложения, отдает > Content-Disposition: "/_download/39" > > Стоит всего лишь несколько укоротить приведённый выше заголовок, как > начинает проходить нормально. > Сомневаюсь что это делает nginx. Debug-лог бы в данном случае прояснил ситуацию. -- Валентин Бартенев ___ nginx-ru mailing list nginx-ru@nginx.org http://mailman.nginx.org/mailman/listinfo/nginx-ru
Re: slice module и proxy_cache_min_uses больше единицы.
25 февраля 2016 г., 18:53 пользователь Evgeniy Berdnikov написал: > > > Проверьте количество инод: df -i. > > Инодов хватает. Проблема именно с местом. Почти все файлы имеют размер слайса - 10 мегабайт, таким образом их влезает не более 22 тысяч. -- WBR, Vadim Lazovskiy ___ nginx-ru mailing list nginx-ru@nginx.org http://mailman.nginx.org/mailman/listinfo/nginx-ru
Re: slice module + thread pools
Hello! On Tue, Feb 23, 2016 at 11:22:45AM +0300, Vadim Lazovskiy wrote: [...] > Проблема 2 (aio включено slice включен): > Если запустить скачивание файла через прокси, скорость очень низкая, > соединение постоянно разрывается. В логах при этом: > 2016/02/23 10:36:11 [alert] 11124#11124: task #1 already active > 2016/02/23 10:36:12 [alert] 11124#11124: task #4 already active > 2016/02/23 10:36:14 [alert] 11124#11124: task #7 already active > 2016/02/23 10:36:17 [alert] 11124#11124: task #10 already active > 2016/02/23 10:37:59 [alert] 11124#11124: task #23 already active > 2016/02/23 10:38:07 [alert] 11124#11124: task #35 already active > 2016/02/23 10:38:17 [alert] 11124#11124: task #37 already active > > Если отключить slice module, все становится хорошо. Это выглядит как проблема при aio threads + sendfile + подзапросы. Workaround - выключить что-нибудь из списка. Just for the record, воспроизводится с помощью тестов как-то так: TEST_NGINX_GLOBALS_HTTP="aio threads; sendfile on;" prove proxy_store.t Патч: # HG changeset patch # User Maxim Dounin # Date 1456417157 -10800 # Thu Feb 25 19:19:17 2016 +0300 # Node ID 06da00f231e74bbb8dbb55fd6abd88ca8b207917 # Parent 463609ba52b07e8e669d83ca7ca7fa754ae5355a Fixed sendfile in threads when used with subrequests. If sendfile in threads where used, it was possible that multiple subrequests will trigger multiple ngx_linux_sendfile_thread() calls, as operations are only serialized in output chain based on r->aio, that is, on subrequest level. This resulted in "task #N already active" alerts, in particular, when running proxy_store.t with "aio threads; sendfile on;". Fix is to tolerate duplicate calls, with an additional safety check that the file is the same as previously used. diff --git a/src/os/unix/ngx_linux_sendfile_chain.c b/src/os/unix/ngx_linux_sendfile_chain.c --- a/src/os/unix/ngx_linux_sendfile_chain.c +++ b/src/os/unix/ngx_linux_sendfile_chain.c @@ -354,6 +354,18 @@ ngx_linux_sendfile_thread(ngx_connection return (ctx->sent == ctx->size) ? NGX_DONE : NGX_AGAIN; } +if (task->event.active && ctx->file == file) { +/* + * tolerate duplicate calls with the same file; + * it can happen due to subrequests, as r->aio only serializes + * operations within a single subrequest + */ + +*sent = 0; + +return NGX_OK; +} + ctx->file = file; ctx->socket = c->fd; ctx->size = size; -- Maxim Dounin http://nginx.org/ ___ nginx-ru mailing list nginx-ru@nginx.org http://mailman.nginx.org/mailman/listinfo/nginx-ru
Re: Nginx не пропускает от proxy длинный Content-Disposition
Здравствуйте! Прошу прощения за недостаточно точный вопрос. Ожидал, что просто уперся в какую-то настройку. Версия 1.8.0, Linux (Ubuntu). Конфиг: location /_download { alias /var/fnc_storage; internal; } location / { proxy_redirect off; proxy_set_header X-Real-IP $remote_addr; proxy_set_header Host localhost:8088; proxy_set_header X-Forwarded-For $remote_addr; proxy_pass http://localhost:8088; } Приложение генерирует заголовки: X-Accel-Redirect: /_download/12345 Content-Disposition: attachment; filename="Odrin_Metod_morfologicheskogo_analiza_texnicheskix_sistem_k.doc"; filename*=UTF-8''%D0%9E%D0%B4%D1%80%D0%B8%D0%BD_%D0%9C%D0%B5%D1%82%D0%BE%D0%B4%20%D0%BC%D0%BE%D1%80%D1%84%D0%BE%D0%BB%D0%BE%D0%B3%D0%B8%D1%87%D0%B5%D1%81%D0%BA%D0%BE%D0%B3%D0%BE%20%D0%B0%D0%BD%D0%B0%D0%BB%D0%B8%D0%B7%D0%B0%20%D1%82%D0%B5%D1%85%D0%BD%D0%B8%D1%87%D0%B5%D1%81%D0%BA%D0%B8%D1%85%20%D1%81%D0%B8%D1%81%D1%82%D0%B5%D0%BC_k.doc (в соответствии с RFC5987). Когда имя файла небольшое - и в кодированном виде длина заголовка меньше примерно 256 (если не ошибся, то почему-то граница 258, а не 256), то всё проходит верно - Nginx отдаёт файл по пути _download и пропускает заголовок Content-Disposition, сформированный приложением. Но вот для приведенного примера заголовка, когда имя файла длинное, Nginx вместо Content-Disposition, полученного от приложения, отдает Content-Disposition: "/_download/39" Стоит всего лишь несколько укоротить приведённый выше заголовок, как начинает проходить нормально. Posted at Nginx Forum: https://forum.nginx.org/read.php?21,264758,264835#msg-264835 ___ nginx-ru mailing list nginx-ru@nginx.org http://mailman.nginx.org/mailman/listinfo/nginx-ru
Re: slice module и proxy_cache_min_uses больше единицы.
On Thu, Feb 25, 2016 at 06:44:03PM +0300, Vadim Lazovskiy wrote: > И чтоб 2 раза не вставать, спрошу, отчего может возникать проблема с > переполнением диска? > Диск 220G, max_cache опустил до 190G, а на деле диск забивается под > завязку, причем именно кешем (proxy_cache_min_uses 1, slice 10m, 10-20 rps). > В temp в этот момент не более 20 временных файлов размером ~ 10 мегабайт. В > кеше все элементы <= 10 мегабайт. > Незакрытых удаленных файлов на диске нет. > В error log куча сообщений c No space left on device. Проверьте количество инод: df -i. -- Eugene Berdnikov ___ nginx-ru mailing list nginx-ru@nginx.org http://mailman.nginx.org/mailman/listinfo/nginx-ru
Re: slice module и proxy_cache_min_uses больше единицы.
25 февраля 2016 г., 16:53 пользователь Roman Arutyunyan написал: > > > Маловат фрагмент. Хотелось бы посмотреть на весь запрос и подзапросы. > > Сразу прошу прощения за размер логов. http://disk.karelia.pro/833rexx/ Два лога: 1. с proxy_cache_min_uses 1. Работает, как задумывалось. Запрос на перемотку можно найти по диапазону 498197221-1279019570. 2. с proxy_cache_min_uses 50. Ломается перемотка из-за игнорирования Range (или учета If-Range, кто его разберет). Запрос на пеермотку можно найти по диапазону 467829492-1279019570. И чтоб 2 раза не вставать, спрошу, отчего может возникать проблема с переполнением диска? Диск 220G, max_cache опустил до 190G, а на деле диск забивается под завязку, причем именно кешем (proxy_cache_min_uses 1, slice 10m, 10-20 rps). В temp в этот момент не более 20 временных файлов размером ~ 10 мегабайт. В кеше все элементы <= 10 мегабайт. Незакрытых удаленных файлов на диске нет. В error log куча сообщений c No space left on device. Спасибо. -- WBR, Vadim Lazovskiy ___ nginx-ru mailing list nginx-ru@nginx.org http://mailman.nginx.org/mailman/listinfo/nginx-ru
Re: zero size buf in output при proxy cache
Максим, здравствуйте! Можем ли мы еще что-то сделать для решения этой проблемы? С уважением, Иван. В письме от 16 февраля 2016 23:04:57 пользователь Maxim Dounin написал: > Hello! > > On Tue, Feb 16, 2016 at 02:00:33PM -0500, iprok wrote: > > Здравствуйте! > > > > На видеостриминговой системе используем два уровня проксей (эджи и > > ориджины). Эджи проксируют клиентов на ориджины, ориджины проксируют эджи > > на сервера-источники видео. Видео отдается в формате HLS: это плейлисты > > (текстовые файлы) и чанки видео (видео-файлы в формате ts). > > > > В локейшенах, проксирующих чанки, на ориджинах и эджах регулярно, хоть и > > относительно не часто (пара десятков за сутки), проскакивают ошибки "zero > > > > size buf in output". Мне кажется причиной является одна из директив: > > proxy_cache_use_stale updating; > > proxy_cache_lock on; > > > > так как до их появления таких ошибок не было. > > > > nginx в основном 1.8.1, но проявиляется так же и на 1.9.11, логи ниже > > делал > > на последней. Используем пакеты для debian8 из репозитория на nginx.org. > > > > Если смотреть access.log, то чанк в помент проявления этой ошибки отдается > > частично, но с кодом 200 (размер в логе меньше реального размера), при > > следующем запросе отдается нормально, и ошибка не проявляется. > > > > Лог кратко (debug.log внизу, здесь и далее в логах вырезана приватная > > информация, так как ошибка вопроизводится только в продакшене): > > > > 2016/02/14 11:09:20 [alert] 30161#30161: *1388932 zero size buf in output > > t:0 r:0 f:0 02387520 02387520-02389356 > > 0-0 while sending to client, client: HIDDENIPV4, server: > > e6.mysite.com, request: "GET /place1/stream/cam13_low-5743015560.ts > > HTTP/1.1", upstream: > > "https://[HIDDENIPV6]:443/place1/video/cam13_low-5743015560.ts";, host: > > "e6.mysite.com", referrer: "https://mysite.com/"; > > 2016/02/14 11:09:23 [alert] 30160#30160: *1389653 zero size buf in output > > t:0 r:0 f:0 022BBC50 022BBC50-022BF185 > > 0-0 while sending to client, client: HIDDENIPV4, server: > > e6.mysite.com, request: "GET /place1/stream/cam13_hi-5297110020.ts > > HTTP/1.1", upstream: > > "https://HIDDENIPV4:443/place1/video/cam13_hi-5297110020.ts";, host: > > "e6.mysite.com", referrer: "https://mysite.com/"; > > [...] > > > Сразу выкладываю debug.log (18 мегабайт в распакованном виде): > > https://kinetiksoft.com/thecloud/index.php/s/5ldvsZFiC2NjpXJ > > Я обрезал только 10 секунд, за которые произошли две ошибки из краткого > > лога в начале сообщения. > > Судя по логам, проблема возникает тогда, когда клиент закрывает > соединение до получения ответа целиком. В обоих случаях перед > alert'ом про "zero size buf" в логах видно такое: > > 2016/02/14 11:09:20 [info] 30161#30161: *1388932 epoll_wait() reported that > client prematurely closed connection (32: Broken pipe) while reading > upstream, client: HIDDENIPV4, server: e6.mysite.com, request: "GET > /place1/stream/cam13_low-5743015560.ts HTTP/1.1", upstream: > "https://[HIDDENIPV6]:443/place1/video/cam13_low-5743015560.ts";, host: > "e6.mysite.com", referrer: "https://mysite.com/"; 2016/02/14 11:09:23 [info] > 30160#30160: *1389653 epoll_wait() reported that client prematurely closed > connection while reading upstream, client: HIDDENIPV4, server: > e6.mysite.com, request: "GET /place1/stream/cam13_hi-5297110020.ts > HTTP/1.1", upstream: > "https://HIDDENIPV4:443/place1/video/cam13_hi-5297110020.ts";, host: > "e6.mysite.com", referrer: "https://mysite.com/"; > > В этом случае nginx продолжает загружать файл с бекенда в кеш, а > после окончания загрузки - пытается отправить последний буфер. И, > видимо, где-то вместе с этим буфером проталкивает в цепочке > фильтров что-то, что ранее счёл свободным (из-за ошибки записи > клиенту), но по факту оно застряло где-то в цепочке фильтров. > > Что именно там происходит и как это поправить - надо смотреть > подробнее. Для начала было бы неплохо убедиться, что сторонних > модулей не используется, а если используются - то проверить, > воспроизводится ли проблема без них. Кроме того, хотелось бы > увидеть вывод "nginx -V". > > (Отмечу также, что в целом ошибка выглядит безвредно - собственно, > логгируемая ошибка и есть основной его эффект. В остальном всё > работает штатно.) ___ nginx-ru mailing list nginx-ru@nginx.org http://mailman.nginx.org/mailman/listinfo/nginx-ru
Re: Вопрос про proxy store
А поженить proxy_store и proxy_cache нельзя? :) например: если нет в proxy_cache, то искать в alias у proxy_store, и если там нет то тогда идти к proxy_pass бекенду на поклон? Наверное выглядит немного бредово, но это отчасти решает проблему бекапа статики которая изначально появляется на бекенде Posted at Nginx Forum: https://forum.nginx.org/read.php?21,264801,264830#msg-264830 ___ nginx-ru mailing list nginx-ru@nginx.org http://mailman.nginx.org/mailman/listinfo/nginx-ru
Re: slice module и proxy_cache_min_uses больше единицы.
On Thu, Feb 25, 2016 at 01:02:13PM +0300, Vadim Lazovskiy wrote: > Здравтсвуйте. > > Наткнулся на непонятную проблему при попытке увеличить proxy_cache_min_uses > в связке co slice module. При proxy_cache_min_uses 1 все работает корректно. > > Имеется фронтенд на nginx 1.9.11 который проксирует и кеширует видео с > нескольких апстримов. Используется slice module. Видео проигрывается > спомощью video.js При попытке увеличить proxy_cache_min_uses возникают > проблемы с перемоткой: > > Запрос №1: > Плеер начинает играть видео. Все штатно. > https://drive.google.com/file/d/0B5-OwnlywJGhY2Rla2RTaVlsd1k/view > > Запрос №2: > Перематываем на произвольную позицию. Браузер делает range-запрос, а > получает 200 и полный Content-Length > https://drive.google.com/file/d/0B5-OwnlywJGhOWZtMTdCYlQ3Z1k/view > > Фрагмент debug-лога: Маловат фрагмент. Хотелось бы посмотреть на весь запрос и подзапросы. [..] -- Roman Arutyunyan ___ nginx-ru mailing list nginx-ru@nginx.org http://mailman.nginx.org/mailman/listinfo/nginx-ru
Re: slice module и proxy_cache_min_uses больше единицы.
> > > Запрос №2: > Перематываем на произвольную позицию. Браузер делает range-запрос, а > получает 200 и полный Content-Length > https://drive.google.com/file/d/0B5-OwnlywJGhOWZtMTdCYlQ3Z1k/view > > > Дело в If-Range. curl-ом без него все хорошо. Но связи с proxy_cache_min_uses я не улавливаю. ___ nginx-ru mailing list nginx-ru@nginx.org http://mailman.nginx.org/mailman/listinfo/nginx-ru
Re: SIGABRT в самописном модуле
Максим, это оно самое! Спасибо огромное! ~~~ wbr, Alexander Uskov - Исходное сообщение - > От: "Maxim Dounin" > Кому: nginx-ru@nginx.org > Отправленные: Среда, 24 Февраль 2016 г 18:48:41 > Тема: Re: Fwd: SIGABRT в самописном модуле > > Совет: используйте для строк ngx_str_t, с явным указанием длины > содержимого. Обе проблемы должны исчезнуть сами по себе. ___ nginx-ru mailing list nginx-ru@nginx.org http://mailman.nginx.org/mailman/listinfo/nginx-ru
slice module и proxy_cache_min_uses больше единицы.
Здравтсвуйте. Наткнулся на непонятную проблему при попытке увеличить proxy_cache_min_uses в связке co slice module. При proxy_cache_min_uses 1 все работает корректно. Имеется фронтенд на nginx 1.9.11 который проксирует и кеширует видео с нескольких апстримов. Используется slice module. Видео проигрывается спомощью video.js При попытке увеличить proxy_cache_min_uses возникают проблемы с перемоткой: Запрос №1: Плеер начинает играть видео. Все штатно. https://drive.google.com/file/d/0B5-OwnlywJGhY2Rla2RTaVlsd1k/view Запрос №2: Перематываем на произвольную позицию. Браузер делает range-запрос, а получает 200 и полный Content-Length https://drive.google.com/file/d/0B5-OwnlywJGhOWZtMTdCYlQ3Z1k/view Фрагмент debug-лога: 2016/02/25 12:16:23 [debug] 17567#17567: *10 accept: 10.0.1.1:2 fd:16 2016/02/25 12:16:23 [debug] 17567#17567: *10 event timer add: 16: 6:1456391843913 2016/02/25 12:16:23 [debug] 17567#17567: *10 reusable connection: 1 2016/02/25 12:16:23 [debug] 17567#17567: *10 epoll add event: fd:16 op:1 ev:80002001 2016/02/25 12:16:23 [debug] 17567#17567: *10 post event 7FBC2167F0D0 2016/02/25 12:16:23 [debug] 17567#17567: *10 delete posted event 7FBC2167F0D0 2016/02/25 12:16:23 [debug] 17567#17567: *10 http wait request handler 2016/02/25 12:16:23 [debug] 17567#17567: *10 malloc: 00C357B0:1024 2016/02/25 12:16:23 [debug] 17567#17567: *10 recv: fd:16 1009 of 1024 2016/02/25 12:16:23 [debug] 17567#17567: *10 reusable connection: 0 2016/02/25 12:16:23 [debug] 17567#17567: *10 posix_memalign: 00C35BC0:4096 @16 2016/02/25 12:16:23 [debug] 17567#17567: *10 http process request line 2016/02/25 12:16:23 [debug] 17567#17567: *10 http request line: "GET /streams/s1.example.com/0/aa7786d88a1529d6ba636e345415b220.mp4 HTTP/1.1" 2016/02/25 12:16:23 [debug] 17567#17567: *10 http uri: "/streams/ s1.example.com/0/aa7786d88a1529d6ba636e345415b220.mp4" 2016/02/25 12:16:23 [debug] 17567#17567: *10 http args: "" 2016/02/25 12:16:23 [debug] 17567#17567: *10 http exten: "mp4" 2016/02/25 12:16:23 [debug] 17567#17567: *10 posix_memalign: 00C280C0:4096 @16 2016/02/25 12:16:23 [debug] 17567#17567: *10 http process request header line 2016/02/25 12:16:23 [debug] 17567#17567: *10 http header: "Host: cache.example.com" 2016/02/25 12:16:23 [debug] 17567#17567: *10 http header: "Connection: keep-alive" 2016/02/25 12:16:23 [debug] 17567#17567: *10 http header: "Accept-Encoding: identity;q=1, *;q=0" 2016/02/25 12:16:23 [debug] 17567#17567: *10 http header: "User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/48.0.2564.116 Safari/537.36" 2016/02/25 12:16:23 [debug] 17567#17567: *10 http header: "Accept: */*" 2016/02/25 12:16:23 [debug] 17567#17567: *10 http header: "Accept-Language: ru-RU,ru;q=0.8,en-US;q=0.6,en;q=0.4,bg;q=0.2" 2016/02/25 12:16:23 [debug] 17567#17567: *10 http header: "Cookie: 2016/02/25 12:16:23 [debug] 17567#17567: *10 http header: "Range: bytes=696653667-1993091904" 2016/02/25 12:16:23 [debug] 17567#17567: *10 http header: "If-Range: Sun, 07 Feb 2016 12:46:26 GMT" 2016/02/25 12:16:23 [debug] 17567#17567: *10 http header done 2016/02/25 12:16:23 [debug] 17567#17567: *10 event timer del: 16: 1456391843913 2016/02/25 12:16:23 [debug] 17567#17567: *10 generic phase: 0 2016/02/25 12:16:23 [debug] 17567#17567: *10 rewrite phase: 1 2016/02/25 12:16:23 [debug] 17567#17567: *10 test location: "/streams/" 2016/02/25 12:16:23 [debug] 17567#17567: *10 test location: ~ "^/streams/(?[^/]+)/(?.*)$" 2016/02/25 12:16:23 [debug] 17567#17567: *10 http regex set $upstream_hostname to "s1.example.com" 2016/02/25 12:16:23 [debug] 17567#17567: *10 http regex set $upstream_uri to "0/aa7786d88a1529d6ba636e345415b220.mp4" 2016/02/25 12:16:23 [debug] 17567#17567: *10 using configuration "^/streams/(?[^/]+)/(?.*)$" 2016/02/25 12:16:23 [debug] 17567#17567: *10 http cl:-1 max:1048576 2016/02/25 12:16:23 [debug] 17567#17567: *10 rewrite phase: 3 2016/02/25 12:16:23 [debug] 17567#17567: *10 http script var 2016/02/25 12:16:23 [debug] 17567#17567: *10 http map started 2016/02/25 12:16:23 [debug] 17567#17567: *10 http script var: " s1.example.com" 2016/02/25 12:16:23 [debug] 17567#17567: *10 http map: "s1.example.com" "1" 2016/02/25 12:16:23 [debug] 17567#17567: *10 http script var: "1" 2016/02/25 12:16:23 [debug] 17567#17567: *10 http script value: "0" 2016/02/25 12:16:23 [debug] 17567#17567: *10 http script equal 2016/02/25 12:16:23 [debug] 17567#17567: *10 http script equal: no 2016/02/25 12:16:23 [debug] 17567#17567: *10 http script if 2016/02/25 12:16:23 [debug] 17567#17567: *10 http script if: false 2016/02/25 12:16:23 [debug] 17567#17567: *10 post rewrite phase: 4 2016/02/25 12:16:23 [debug] 17567#17567: *10 generic phase: 5 2016/02/25 12:16:23 [debug] 17567#17567: *10 generic phase: 6 2016/02/25 12:16:23 [debug] 17567#17567: *10 generic phase: 7 2016/02/25 12:16:23 [debug] 17567#17567: *10 access phase: 8 2016/02/25 12:16:23 [debug] 17567#17567: *10 access: D52B0
Re: модуль на заказ
Присоединяюсь к советующему X-Accel-Redirect. Тоже рекомендую. И надежнее и функциональнее. 25 февраля 2016 г., 11:52 пользователь Alexander Uskov написал: > Как минимум random и floor. > > А вообще реализация нужной мне ф-ции на js - > https://gist.github.com/larchanka/7080820/ > > ~~~ > wbr, Alexander Uskov > > - Исходное сообщение - > > От: "Igor Sysoev" > > Кому: nginx-ru@nginx.org > > Отправленные: Четверг, 25 Февраль 2016 г 13:35:39 > > Тема: Re: модуль на заказ > > > > On 25 Feb 2016, at 07:48, Alexander Uskov wrote: > > > > > Попробую Lua, так как яваскрипт пока нефункционален (нет класса > > > Math), > > > > А что нужно в Math? > > > > > > -- > > Igor Sysoev > > http://nginx.com > > > > ___ > > nginx-ru mailing list > > nginx-ru@nginx.org > > http://mailman.nginx.org/mailman/listinfo/nginx-ru > ___ > nginx-ru mailing list > nginx-ru@nginx.org > http://mailman.nginx.org/mailman/listinfo/nginx-ru > ___ nginx-ru mailing list nginx-ru@nginx.org http://mailman.nginx.org/mailman/listinfo/nginx-ru
Re: модуль на заказ
Как минимум random и floor. А вообще реализация нужной мне ф-ции на js - https://gist.github.com/larchanka/7080820/ ~~~ wbr, Alexander Uskov - Исходное сообщение - > От: "Igor Sysoev" > Кому: nginx-ru@nginx.org > Отправленные: Четверг, 25 Февраль 2016 г 13:35:39 > Тема: Re: модуль на заказ > > On 25 Feb 2016, at 07:48, Alexander Uskov wrote: > > > Попробую Lua, так как яваскрипт пока нефункционален (нет класса > > Math), > > А что нужно в Math? > > > -- > Igor Sysoev > http://nginx.com > > ___ > nginx-ru mailing list > nginx-ru@nginx.org > http://mailman.nginx.org/mailman/listinfo/nginx-ru ___ nginx-ru mailing list nginx-ru@nginx.org http://mailman.nginx.org/mailman/listinfo/nginx-ru
Пара комментариев о директиве expires
Доброго дня. 1. Директива expires создает два хедера — Expires и Cache-Control. Однако, я бы хотел также добавить другие параметры Cache-Control, например, "public" или "no-store". Сделав это через обычный add_header, на выходе я получу два хедера Cache-Control: в одном "max-age" (созданный директивой expires), в другом "public" (созданный директивой add_header), вместо одного "max-age=..., public". Нет, это не катастрофа, но налицо неэффективное использование bandwidth. Возможные варианты решения: а) опционально мержить значения всех хедеров Cache-Control в один хедер; б) примерживать результат работы expires (max-age или no-cache) к ранним add_header Cache-Control, если таковые были; в) добавить в expires третий параметр, в котором пользователь мог бы указать дополнительные опции Cache-Control (имхо самый адекватный вариант). 2. expires max это max-age на 10 лет и Expires на 2037 год. Однако RFC 2616 (https://www.w3.org/Protocols/rfc2616/rfc2616-sec14.html) гласит: To mark a response as "never expires," an origin server sends an Expires date approximately one year from the time the response is sent. HTTP/1.1 servers SHOULD NOT send Expires dates more than one year in the future. Да, should not это не must not, да и через каких-то 20 с лишним лет вопрос отпадёт сам собой, но всё же. Гугл, кстати, тоже рекомендует максимум год (https://developers.google.com/speed/docs/insights/LeverageBrowserCaching): We recommend a minimum cache time of one week and preferably up to one year for static assets, or assets that change infrequently. Спасибо за внимание. Posted at Nginx Forum: https://forum.nginx.org/read.php?21,264815,264815#msg-264815 ___ nginx-ru mailing list nginx-ru@nginx.org http://mailman.nginx.org/mailman/listinfo/nginx-ru