Хабр Курсы для всех
РЕКЛАМА
Практикум, Хекслет, SkyPro, авторские курсы — собрали всех и попросили скидки. Осталось выбрать!
Хабр доступен 24/7 благодаря поддержке друзей
Комментарии 19
Идея интересная, спасибо. В перспективе не думаете переложить отдачу статики и подобные проверки на nginx?
Возможно, но позже. Опыт работы с Nginx пока скудный — только на уровне допила ISPmanager.
«В перспективе не думаете переложить отдачу статики и подобные проверки на nginx?»
У нас используется похожая схема, и в ней есть nginx.
В нашей схеме наличие сгенерированного файла проверяет сначала nginx и если нужная картинка уже есть — отдаёт её своими силами.
Если же файл не найден — происходит передача запроса Апачу, а далее всё по похожей схеме как в данной статье
У нас используется похожая схема, и в ней есть nginx.
В нашей схеме наличие сгенерированного файла проверяет сначала nginx и если нужная картинка уже есть — отдаёт её своими силами.
Если же файл не найден — происходит передача запроса Апачу, а далее всё по похожей схеме как в данной статье
Я описанный вами первый метод уже несколько лет использую в работе. К стати, узнал я о нем на Хабре, так что тема, как говорится, паленая :)
Рад за вас. Метод простой, но действенный. И уж 100% я не первый. Просто я перерыл google в поисках чего-то подобного но не нашел (возможно потому, что с google общаюсь исключительно на английском). На самом деле у меня есть и чуть более сложный вариант с использованием setenv но я не стал его сюда публиковать, т.к. данный модуль не везде включён. В нем интерпретатору передаются оба маршрута и шаблон преобразования через окружение. А одна из задач поста немного переосмыслить такую элементарную штуку как htaccess и mod_rewrite. Ведь представленные на просторах интернета рецепты напоминают фрагмент монолога Р. Карцева «Отец»: "… Папаня, на уникальных японских электронных микроскопах пальто висят. — Ну вам наша вешалка?.."
Бандл для Symfony2 с описанным подходом: github.com/avalanche123/AvalancheImagineBundle
По такой же логике можно сделать склеивание/минимизацию css и js
Склеивание и минимизация должны выполняться перед или во время деплоя.
Смотря что и как склеивать. Сомневаюсь что у кого-нибудь найдется пара тысяч css или js файлов для регулярного сжатия или склеивания… если это конечно не репозиторий сборных библиотек. А вот даже в том же магазине уже более 30 000 изображений только в каталоге товаров. И вопрос оптимизации и удобства в управлении — №1.
1.
А почему не положить thumb.php в папку /images/thumb/? остальные файлы будут работать как и раньше. Ведь проблем с отдачей оригинальных картинок нет, значит надо бить именно по миниатюркам. Так бьете по воробьям из пушки.
2.
Когда работаем только с миниатюрками, зачем web-серверу искать несколько файлов, получается по вашему конфигу, на один первый запрос(когда нет миниатюрки) — 6 обращений к диску. Думаю можно просто посмотреть есть файл или нет, если нет отправить на thumb.php, а вот он уже пусть сделает svg -> png. В php через функцию glob() можно по маске найти файл(ы), а там уже легко понять что хотят от нас. К тому же решается проблема, если завтра кто-то захочет jpg, а не png. По вашему конфигу web-сервер будет отдавать ту миниатюру, которую сделали первую. А так php может ложить картинки в том же расширении что и запросили.
А почему не положить thumb.php в папку /images/thumb/? остальные файлы будут работать как и раньше. Ведь проблем с отдачей оригинальных картинок нет, значит надо бить именно по миниатюркам. Так бьете по воробьям из пушки.
2.
Когда работаем только с миниатюрками, зачем web-серверу искать несколько файлов, получается по вашему конфигу, на один первый запрос(когда нет миниатюрки) — 6 обращений к диску. Думаю можно просто посмотреть есть файл или нет, если нет отправить на thumb.php, а вот он уже пусть сделает svg -> png. В php через функцию glob() можно по маске найти файл(ы), а там уже легко понять что хотят от нас. К тому же решается проблема, если завтра кто-то захочет jpg, а не png. По вашему конфигу web-сервер будет отдавать ту миниатюру, которую сделали первую. А так php может ложить картинки в том же расширении что и запросили.
1.
.htaccess тоже идет в /images/thumb/
.htaccess тоже идет в /images/thumb/
по-хорошему из папки /images/ ничего выполняться не должно, скрипты должны лежать отдельно от директорий загрузки
Да, действительно, *.php хорошо бы вообще убрать отсюда и нормально настроить .htaccess только на отдачу файлов, просто тут обсуждали «нагрузку». И я просто написал свой опыт, что лучше работать только с миниатюрками, а не со всеми картинками.
Так получается, если была бы папка /files/images/, то .htaccess лежал бы в /files? с дополнительной проверкой картинка это или нет, на примере проверки миниатюрка или нет.
Так получается, если была бы папка /files/images/, то .htaccess лежал бы в /files? с дополнительной проверкой картинка это или нет, на примере проверки миниатюрка или нет.
1.
А зачем класть сам скрипт? Достаточно разместить там сам .htaccess с соответствующими изменениями. Скрипт может лежать в любом месте в пределах публичной папки чтобы Apache мог туда перенаправить. Если разместить вне DOCUMENT_ROOT или в директории с ограничением доступа доступа к скрипту не будет.
2.
Так суть как раз в том чтобы не дёргать скрипт по поводу и без. Apache согласно набору правил сам определяет целесообразность запуска скрипта проверяя наличие исходника для преобразования. А сохранять можно хоть в pdf. Если конечно очень хочется. И будет лежать 1.jpg 1.png 1.gif и т.д. в папке /images/thumb/a.
И еще… даже проверять на редирект в скрипте не обязательно. Кидаем в QUERY_STRING ключик и добавляем проверочку.
А при хранении шаблонов преобразований в файлах, можно даже застраховаться от вызова миниатюризатора с неверным шаблоном. И все это без запуска скрипта.
А зачем класть сам скрипт? Достаточно разместить там сам .htaccess с соответствующими изменениями. Скрипт может лежать в любом месте в пределах публичной папки чтобы Apache мог туда перенаправить. Если разместить вне DOCUMENT_ROOT или в директории с ограничением доступа доступа к скрипту не будет.
2.
Так суть как раз в том чтобы не дёргать скрипт по поводу и без. Apache согласно набору правил сам определяет целесообразность запуска скрипта проверяя наличие исходника для преобразования. А сохранять можно хоть в pdf. Если конечно очень хочется. И будет лежать 1.jpg 1.png 1.gif и т.д. в папке /images/thumb/a.
И еще… даже проверять на редирект в скрипте не обязательно. Кидаем в QUERY_STRING ключик и добавляем проверочку.
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_URI} ^/([^/]+)/thumb/([^/]+)(/.+)?/(.+)\.(jpe?g|png|gif|svgz?|tiff?)$
RewriteCond %{DOCUMENT_ROOT}/%1%3/%4.%5 –f
RewriteRule ^(.*)$ thumb.php?cs=eaf59842b9a337232f32b05d5b1f0c19 [L,QSA]
RewriteCond %{REQUEST_FILENAME} thumb\.php
RewriteCond %{QUERY_STRING} !^cs=eaf59842b9a337232f32b05d5b1f0c19$
RewriteRule . - [F,L]
А при хранении шаблонов преобразований в файлах, можно даже застраховаться от вызова миниатюризатора с неверным шаблоном. И все это без запуска скрипта.
1. Да, я тут немного запутался, я про .htaccess, скрипт отдельно должен лежать. Выше писали.
2. Я просто не люблю логику в разные места закладывать, стараюсь чтоб все в одном месте было. Так у вас не будет разницы какой web-сервер стоит. Nginx, apache и т.д. И другой программист скажет спасибо; Допустим я на локальной машине использую связку nginx + php-fpm, ваш проект не так просто будет поднять, весь .htaccess я должен переписать под nginx. В моем варианте любой web-сервер должен сделать только одно, если нет файла, то спроси у приложения. Завтра вы по разному URL'у сможете делать разные миниатюрки, с белым фоном/прозрачным, 120x90px, 600x800px, gif/png/jpeg и т.д. И не надо лезть и вспоминать как писать правила для apache/nginx, достаточно будет настроить php. В основном вы же пишите на php?
Как примеры
Все это сможет сделать php, главное чтоб ему web-сервер не мешал.
2. Я просто не люблю логику в разные места закладывать, стараюсь чтоб все в одном месте было. Так у вас не будет разницы какой web-сервер стоит. Nginx, apache и т.д. И другой программист скажет спасибо; Допустим я на локальной машине использую связку nginx + php-fpm, ваш проект не так просто будет поднять, весь .htaccess я должен переписать под nginx. В моем варианте любой web-сервер должен сделать только одно, если нет файла, то спроси у приложения. Завтра вы по разному URL'у сможете делать разные миниатюрки, с белым фоном/прозрачным, 120x90px, 600x800px, gif/png/jpeg и т.д. И не надо лезть и вспоминать как писать правила для apache/nginx, достаточно будет настроить php. В основном вы же пишите на php?
Как примеры
/images/a/b/filename.jpg — оригинал
/images/thumb/a/b/filename.jpg — стандартная миниатюрка
/images/thumb/a/b/filename.jpg.png — стандартный размер, но в png
/images/thumb/a/b/filename.jpg_120x90.jpg — размер 120x90
/images/thumb/a/b/filename.jpg_600x800.png — размер 600x800
Все это сможет сделать php, главное чтоб ему web-сервер не мешал.
Речь то не о PHP. Если не обратили внимание, речь идет о распределении нагрузки. Работа любого интерпретатора изначально более дорогая (создание окружения, подгрузка кода и т.д.) чем минимальная логика на уровне HTTP сервера. А для несчастных владельцев CGI особенно, поскольку интерпретатор при использовании того же PHP в качестве модуля или FCGI уже запущен и ждёт команды, а при CGI для начала работы приложения требуется больше времени. При этом у нас всегда есть сам сервер. И если есть возможность за счёт его способностей снять лишнюю нагрузку с интерпретатора — грех этим не воспользоваться. В данном случае приводится лишь пример как не запускать скрипт впустую благодаря mod_rewrite.
И вообще я сталкивался столько с перенаправлениями типа:
или
что аж страшно… А потом владельцы сайтов начинают верещать «Ой мне письмо пришло от хостера, что у меня превышение процессорного времени и меня отключат». А что удивляться? Времена меняются. Если лет 6-7 назад подсчёт процессорного времени был в диковинку, то сейчас почти на каждом шагу. На одном сайте даже слайдер починял — изображения 1200х450 генерировались при каждом заходе на страницу.
И вообще я сталкивался столько с перенаправлениями типа:
RewriteCond %{REQUEST_URI} thumb
RewriteRule ^(.*)$ thumb.php [L]
или
<FILES thumb>
# давай работай что-нибудь
</FILES>
что аж страшно… А потом владельцы сайтов начинают верещать «Ой мне письмо пришло от хостера, что у меня превышение процессорного времени и меня отключат». А что удивляться? Времена меняются. Если лет 6-7 назад подсчёт процессорного времени был в диковинку, то сейчас почти на каждом шагу. На одном сайте даже слайдер починял — изображения 1200х450 генерировались при каждом заходе на страницу.
Но я ведь не говорю, что web-сервер не должен проверять есть файл или нет и каждый раз нарезал новую картинку. Вот если бы web-сервер еще сам нарезал, тогда я бы понял. Так кстати умеет nginx с модулем «http_image_filter_module». Или лучше отправлял на другое приложение (утилиту), которое нарезает быстрее и меньше памяти использует. Но это все оптимизация на уровне очень высоконагруженных проектов, не думаю что каждый проект такой нагруженный, другое дело что завтра с этим кодом кто-то будет работать. Часы программисты сейчас дороже. Поэтому приложения должны быть маскимально простыми и понятными.
Думаю у нас спор на пустом месте. Разница в нагрузке тут минимальная, так как и в Вашем и в моем варианте картинка нарезается один раз. Я просто предложил более гибкий вариант, в котором web-сервер не мешает.
Думаю у нас спор на пустом месте. Разница в нагрузке тут минимальная, так как и в Вашем и в моем варианте картинка нарезается один раз. Я просто предложил более гибкий вариант, в котором web-сервер не мешает.
В том то и дело что спор на пустом месте. Ведь и ваш пример можно посадить на те же салазки. И поверьте, сервер не будет мешать а только помогать. По первому примеру и с таким вот регулярником например.
Главное скрипт получит запрос только если есть с чем ему работать. А если поставить ограничение на сам скрипт и проверять на редирект и реферер то он вообще лишний раз не запустится.
^/([^/]+)/thumb/(.+)?/([^\.]+)\.(jpe?g|png|gif|svgz?|tiff?)(.+)?$
Главное скрипт получит запрос только если есть с чем ему работать. А если поставить ограничение на сам скрипт и проверять на редирект и реферер то он вообще лишний раз не запустится.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Как заставить Apache работать или как я реализую создание миниатюр изображений в своих проектах