Re: try files - принудительно "перейти" к следующему варианту
Дмитрий Герасимов Wrote: --- > Вообщем всем спасибо. Сегодня узнал о существовании incron (век живи, > век учись), при помощи онного и решил проблему Есть аналог API в systemd https://www.freedesktop.org/software/systemd/man/systemd.path.html Posted at Nginx Forum: https://forum.nginx.org/read.php?21,274006,274062#msg-274062 ___ nginx-ru mailing list nginx-ru@nginx.org http://mailman.nginx.org/mailman/listinfo/nginx-ru
Re: try files - принудительно "перейти" к следующему варианту
Вообщем всем спасибо. Сегодня узнал о существовании incron (век живи, век учись), при помощи онного и решил проблему Posted at Nginx Forum: https://forum.nginx.org/read.php?21,274006,274061#msg-274061 ___ nginx-ru mailing list nginx-ru@nginx.org http://mailman.nginx.org/mailman/listinfo/nginx-ru
Re: try files - принудительно "перейти" к следующему варианту
Если вы про gitlab.com, там из коробки есть gitlab-ci, т.е. выкладку можно привязать к комиту 2 мая 2017 г. 23:18 пользователь "Vasiliy P. Melnik" < nginx-fo...@forum.nginx.org> написал: > гит - это не сложно, можно на гитлабе аккаунты сделать, там кажись 5 > аккаунтов бесплатно, научить программеров его использовать - тоже ничего > выдающегося. Дальше скрипт деплоя и в него же добавить архивирование нужных > файлов, отдавать через gzip_static > > Posted at Nginx Forum: https://forum.nginx.org/read. > php?21,274006,274055#msg-274055 > > ___ > 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: try files - принудительно "перейти" к следующему варианту
гит - это не сложно, можно на гитлабе аккаунты сделать, там кажись 5 аккаунтов бесплатно, научить программеров его использовать - тоже ничего выдающегося. Дальше скрипт деплоя и в него же добавить архивирование нужных файлов, отдавать через gzip_static Posted at Nginx Forum: https://forum.nginx.org/read.php?21,274006,274055#msg-274055 ___ nginx-ru mailing list nginx-ru@nginx.org http://mailman.nginx.org/mailman/listinfo/nginx-ru
Re: try files - принудительно "перейти" к следующему варианту
2 мая 2017 г., 22:02 пользователь "Дмитрий Герасимов" < nginx-fo...@forum.nginx.org> написал: > Илья Шипицин Wrote: > --- > > > gzip не очень затратный по ресурсам вариант компрессии. > > мы в тесте видим производительность 24 мегабайта в секунду на 1 ядро. > > нет особых проблем с тем, чтобы жать на лету. > > > > вы точно считали, что предварительное сжатие вам дает выигрыш ? > > > > (в случае brotli это действительно так > > https://blog.cloudflare.com/results-experimenting-brotli/ ) > > > Сейчас уже не могу сказать - старого сервера уже два дня нет. Но думаю, что > всё-таки да - быстрей. По логике - просто отдать файл должно быть быстрей > чем сжать (причём сжать для каждого нового клиента) и отдать сжатый > контент. > > неважно, есть старый сервер или нет. решение перейти на эту схему было принято, когда он работал, и вероятно, было исследование на тему "как лучше". чтобы показать результаты исследования, необязательно, чтобы сервер был сейчас доступен > Posted at Nginx Forum: https://forum.nginx.org/read. > php?21,274006,274051#msg-274051 > > ___ > 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: try files - принудительно "перейти" к следующему варианту
Илья Шипицин Wrote: --- > gzip не очень затратный по ресурсам вариант компрессии. > мы в тесте видим производительность 24 мегабайта в секунду на 1 ядро. > нет особых проблем с тем, чтобы жать на лету. > > вы точно считали, что предварительное сжатие вам дает выигрыш ? > > (в случае brotli это действительно так > https://blog.cloudflare.com/results-experimenting-brotli/ ) Сейчас уже не могу сказать - старого сервера уже два дня нет. Но думаю, что всё-таки да - быстрей. По логике - просто отдать файл должно быть быстрей чем сжать (причём сжать для каждого нового клиента) и отдать сжатый контент. Posted at Nginx Forum: https://forum.nginx.org/read.php?21,274006,274051#msg-274051 ___ nginx-ru mailing list nginx-ru@nginx.org http://mailman.nginx.org/mailman/listinfo/nginx-ru
Re: try files - принудительно "перейти" к следующему варианту
2 мая 2017 г., 21:33 пользователь "Дмитрий Герасимов" < nginx-fo...@forum.nginx.org> написал: > Илья Шипицин Wrote: > --- > > > > там есть как минимум 2 сценария - либо обработка стилей и скриптов в > > реальном времени, для этого нужен сервер на node.js, и это - да, из > > пушки > > по воробьям, либо предварительная упаковка скриптов и стилей в момент > > выкладки сайта. кажется, второе, это ваш случай > > > > > Если бы это были только скрипты и стили, то проблемы нет - я могу их > сжимать > на момент подключения к странице (изначально так и было). > Но там ещё шрифты, xml-ки для разных сервисов, pdf, которые постоянно > изменяются > > gzip не очень затратный по ресурсам вариант компрессии. мы в тесте видим производительность 24 мегабайта в секунду на 1 ядро. нет особых проблем с тем, чтобы жать на лету. вы точно считали, что предварительное сжатие вам дает выигрыш ? (в случае brotli это действительно так https://blog.cloudflare.com/results-experimenting-brotli/ ) > Posted at Nginx Forum: https://forum.nginx.org/read. > php?21,274006,274049#msg-274049 > > ___ > 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: try files - принудительно "перейти" к следующему варианту
Илья Шипицин Wrote: --- > > там есть как минимум 2 сценария - либо обработка стилей и скриптов в > реальном времени, для этого нужен сервер на node.js, и это - да, из > пушки > по воробьям, либо предварительная упаковка скриптов и стилей в момент > выкладки сайта. кажется, второе, это ваш случай > Если бы это были только скрипты и стили, то проблемы нет - я могу их сжимать на момент подключения к странице (изначально так и было). Но там ещё шрифты, xml-ки для разных сервисов, pdf, которые постоянно изменяются Posted at Nginx Forum: https://forum.nginx.org/read.php?21,274006,274049#msg-274049 ___ nginx-ru mailing list nginx-ru@nginx.org http://mailman.nginx.org/mailman/listinfo/nginx-ru
Re: try files - принудительно "перейти" к следующему варианту
Vasiliy P. Melnik Wrote: --- > зачем такие сложности? как происходит деплой у Вас ? Да его как такового нет :). Коллектив у нас небольшой. Вся техническая составляющая сайта на мне. Есть девочка дизайнер, которая хочет видеть свои правки "здесь и сейчас". Плюс начальник, который в моё отсутствие и под мою диктовку может что-нибудь подправить. Posted at Nginx Forum: https://forum.nginx.org/read.php?21,274034,274038#msg-274038 ___ nginx-ru mailing list nginx-ru@nginx.org http://mailman.nginx.org/mailman/listinfo/nginx-ru
Re: try files - принудительно "перейти" к следующему варианту
Попросите фронтендеров прикрутить webpack 2 мая 2017 г. 20:31 пользователь Дмитрий Герасимов < nginx-fo...@forum.nginx.org> написал: > Илья Шипицин Wrote: > --- > > А на каком движке написан сайт? > > Полностью рукописный > > Posted at Nginx Forum: https://forum.nginx.org/read. > php?21,274034,274035#msg-274035 > > ___ > 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: try files - принудительно "перейти" к следующему варианту
зачем такие сложности? как происходит деплой у Вас ? Posted at Nginx Forum: https://forum.nginx.org/read.php?21,274034,274037#msg-274037 ___ nginx-ru mailing list nginx-ru@nginx.org http://mailman.nginx.org/mailman/listinfo/nginx-ru
Re: try files - принудительно "перейти" к следующему варианту
P.S. я также рассматривал вариант сделать подзапрос после отдачи основного файла. Но так, чтобы nginx не дожидался его завершения (что-то типо javascript ajax, и да - nginScript установлен). В принципе задержка в один запрос (когда клиент получит старую версию из gz файла) это некритично. Но ничего похожего не нашел Posted at Nginx Forum: https://forum.nginx.org/read.php?21,274034,274036#msg-274036 ___ nginx-ru mailing list nginx-ru@nginx.org http://mailman.nginx.org/mailman/listinfo/nginx-ru
Re: try files - принудительно "перейти" к следующему варианту
Илья Шипицин Wrote: --- > А на каком движке написан сайт? Полностью рукописный Posted at Nginx Forum: https://forum.nginx.org/read.php?21,274034,274035#msg-274035 ___ nginx-ru mailing list nginx-ru@nginx.org http://mailman.nginx.org/mailman/listinfo/nginx-ru
Re: try files - принудительно "перейти" к следующему варианту
А на каком движке написан сайт? 2 мая 2017 г. 20:07 пользователь Дмитрий Герасимов < nginx-fo...@forum.nginx.org> написал: > Vasiliy P. Melnik Wrote: > --- > > я не понял как вы проверяете устаревание файла. Каждый раз дергать > > скрипт и он сверяет файл оригинальный и файл сжатый? try_files он ведь > > только наличие проверяет > > Да. К сожалению сейчас так - при каждом обращении сверяю даты модификации > оригинального и сжатого файла. Проблема в том, что с одной стороны есть > несколько людей которые правят стили, скрипты и т.д. и заставить их > создавать сжатую версию я не могу. С другой - на каждый запрос нового > пользователя сжимать на лету было довольно накладно (одноядерный проц. на > котором ещё и ssl/http2). > > Отсюда и возникла идея делать подзапрос, прежде чем отдать файл. И ничего > лучше чем auth_request на тот момент не придумалось. > А в идеале мне это виделось так, чтобы try_files в первом локейшене > проверял > даты модификации и если в нём пересоздавалась сжатая версия, то отдать её и > одновременно сохранить (fastcgi_store). Если файл не менялся - то перейти > на > след. вариант и там как обычно > > Posted at Nginx Forum: https://forum.nginx.org/read. > php?21,274006,274032#msg-274032 > > ___ > 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: try files - принудительно "перейти" к следующему варианту
как по мне, то я бы использовал ngx_http_gzip_static_module , а проход и
сверку версий стилей и если отличаются, компрессию - делал бы из скрипта
деплоя. Опять же, если чего-то пропустил скрипт компрессии, то обычный gzip
on решит вопрос
в действительности то что вам хочется это стандартная конструкция - вызвать
скрипт, если файл отсутствует
З.Ы. с expires 7d; у меня были проблемы - кеш не чистился. Конструкция не
моя - зачем была нужна хз. Разбираться не стал и просто переделал на
стандартное кеширование нгинксом
#location /pic {
#root /var/www/i/cache/image/;
#try_files $uri @pic_fetch;
#expires 7d;
#}
#
#location @pic_fetch {
#proxy_pass http://Backend;
#rewrite ^/pic/(.*) /image.php?params=$1 break;
#}
#
Posted at Nginx Forum:
https://forum.nginx.org/read.php?21,274006,274033#msg-274033
___
nginx-ru mailing list
nginx-ru@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx-ru
Re: try files - принудительно "перейти" к следующему варианту
Vasiliy P. Melnik Wrote: --- > я не понял как вы проверяете устаревание файла. Каждый раз дергать > скрипт и он сверяет файл оригинальный и файл сжатый? try_files он ведь > только наличие проверяет Да. К сожалению сейчас так - при каждом обращении сверяю даты модификации оригинального и сжатого файла. Проблема в том, что с одной стороны есть несколько людей которые правят стили, скрипты и т.д. и заставить их создавать сжатую версию я не могу. С другой - на каждый запрос нового пользователя сжимать на лету было довольно накладно (одноядерный проц. на котором ещё и ssl/http2). Отсюда и возникла идея делать подзапрос, прежде чем отдать файл. И ничего лучше чем auth_request на тот момент не придумалось. А в идеале мне это виделось так, чтобы try_files в первом локейшене проверял даты модификации и если в нём пересоздавалась сжатая версия, то отдать её и одновременно сохранить (fastcgi_store). Если файл не менялся - то перейти на след. вариант и там как обычно Posted at Nginx Forum: https://forum.nginx.org/read.php?21,274006,274032#msg-274032 ___ nginx-ru mailing list nginx-ru@nginx.org http://mailman.nginx.org/mailman/listinfo/nginx-ru
Re: try files - принудительно "перейти" к следующему варианту
я не понял как вы проверяете устаревание файла. Каждый раз дергать скрипт и он сверяет файл оригинальный и файл сжатый? try_files он ведь только наличие проверяет Posted at Nginx Forum: https://forum.nginx.org/read.php?21,274006,274030#msg-274030 ___ nginx-ru mailing list nginx-ru@nginx.org http://mailman.nginx.org/mailman/listinfo/nginx-ru
Re: try files - принудительно "перейти" к следующему варианту
Vasiliy P. Melnik Wrote: --- > а чем ну устраивает стандартный путь? > > gzip on; > gzip_min_length 1024; > gzip_comp_level 1; > gzip_proxied any; > gzip_types text/plain text/xml text/css application/x-javascript > text/javascript application/json; > gzip_buffers 4 64k; А смысл для каждого клиента "на лету" сжимать один и тот-же файл? По сути в /gzipper лежит простенький скрипт, который проверял наличие .gz файла и сравнивал с датой модификации оригинального файла. Ну и если хоть один пункт не совпадал, то (пере)создавал .gz версию. Опять-же старый сервер был слабенький и приходилось экономить на всём (тотальный кеш всему). И вариант с auth_request рабочий - просто не нравится то, что я его не по назначению использую Posted at Nginx Forum: https://forum.nginx.org/read.php?21,274006,274024#msg-274024 ___ nginx-ru mailing list nginx-ru@nginx.org http://mailman.nginx.org/mailman/listinfo/nginx-ru
Re: try files - принудительно "перейти" к следующему варианту
а чем ну устраивает стандартный путь? gzip on; gzip_min_length 1024; gzip_comp_level 1; gzip_proxied any; gzip_types text/plain text/xml text/css application/x-javascript text/javascript application/json; gzip_buffers 4 64k; Posted at Nginx Forum: https://forum.nginx.org/read.php?21,274006,274023#msg-274023 ___ nginx-ru mailing list nginx-ru@nginx.org http://mailman.nginx.org/mailman/listinfo/nginx-ru
