Pull to refresh

Comments 42

А этот модуль направлено сохранять превью получается не умеет? Просто каждые 24ч вы все равно генерите новую превью.
Точно, дочитал ман по нему как раз.
Можно поставить 1y
Можно сделать через proxy_store, можно поставить больше таймаут, это уже дело вкуса.
А можно радоваться тому, что неиспользуемые миниатюрки сами уничтожаться через сутки.
Всё зависит от того, чего мы хотим добиться
Так они полюбому будут удаляться из-за параметра max_size=5G
Если будешь использовать proxy_store то, не будут
Сори, имел ввиду, если выставить большой proxy_cache_valid и оставить max_size=5G.
В одном проекте тоже решили ресайзить картинки при отдаче. Но пошли другим путём: nginx отдаёт запрос к php, тот в свою очередь ресайзит с использованием imagemagick и отдаёт картинку в nginx на кеширование. Такой способ выбрали из-за больших возможностей imagemagick.
Перед тем как выбрать ресайз при отдаче походил по форумам веб-кодеров с вопросом стоит ли такое делать. Нам рекомендовали хранить оригиналы и при добавлении нового формата просто все оригиналы переделывать под новый формат. Но немного прикинув решили всё же делать при отдаче.
Кстати connect.ua тоже делает через imagemagick и при отдаче.
Вариант с проксированием своего сервера node.js тоже рассматривался, но решили, что возможностей ngx_http_image_filter_module нам хватит, а если не хватит, то можно модуль дописать.

На самом деле большие возможности ImageMagick тут просто не нужны, нужен просто ресайз картинок, иногда ресайз с кропом, это модуль умеет.
С предопределенными размерами ддосерам — бой :)
Сервер приложений заддосить всё же проще. А тут нужен нетривиальный сценарий атаки + плюс довольно большое количество запросов.
Вы учите плохому: if ($uri…
Для этого есть выделения в location'ах.
location-ов может быть больше одного, тогда придётся дублировать (один для image_filter resize, второй для crop, например). Кроме того, с $1 $2 были проблемы в location, поэтому я и вынес определение размеров наружу
Это не оправдывает внезапных сегфолтов и обрезаний скриптов у nginx.

А для избавления от $1 и $2 есть именованные location:
location ~* \/images\/resize_(?<img>[0-9a-f]*)_(?<w>[0-9]{1-4})_(?<h>[0-9]{1-4})\.(?<ext>(jpg|gif|png))
{
    alias /images/$img.$ext;
    image_filter resize $w $h;
}

Красиво, удобно, понятно, не сломается.
Ой, Игорь уже написал это ниже :(
Каких сегфолтов и обрезаний скриптов? Всё работает чётко
Сервер по-русски называется энджиникс, а не нгинкс, вы бы лучше на nginx везде заменили.
дада. Пруф:
nginx [engine x] — это HTTP-сервер и почтовый прокси-сервер. Я начал разрабатывать nginx весной 2002 года, а осенью 2004 года вышел первый публично доступный релиз.
© sysoev.ru/nginx/
о, как раз интересовало как знакомый сделал сервис с превьюшками (:
Не нужно никаких if ($uri), rewrite'ов и break'ов:

location ~ ^/(\d+|-)x(\d+|-)/(.*\.(?:jpg|gif|png))$ {
alias /path/to/images/$3;
image_filter resize $1 $2;
}
Можно и так.
Просто у меня несколько location-ов в таком случае /path/to/images/ придётся указывать в каждом.
И это прекрасно. Нужно концентрировать всю логику обработки запроса в одном location'е, который видно на одном экране, а не размазывать по всему конфигу, который с течением времени будет только расти.
Кстати, сейчас при отсутствии файла image_filter 404 ответ превращает в 415, кажется несколько нелогичным
Потому что 404, равно как и 500, для фильтра — не картинка.
Я понимаю почему, но мне кажется это нелогичным. Ответ Not Modified этот модуль к примеру не фильтрует.
И как отловить 404? Я использую вот такой, не самый элегантный способ:
location ... {
    ...
    if (!-f $request_filename) {
        rewrite ^.*$ /notfound last;
    }
    image_filter resize $w $h;
    ...
}

location = /notfound {
    return 404;
}
Плохая идея ресайзить картинки с помощью асинхронного сервера.
Лучше передать ети обязаности на бекенд.
Если сервер больше ничем не занимается, то в общем всё равно. бекэнд или сам сервер сколько ядер столько и есть.
Это верно только в том случаи, если сервер отдает только картинки.
А если еще и статику то нет
при особом желании можно запустить два нгинкса, задним жать передним кэшировать и выдавать статику. Писать какой-то кастомный бекэнд — напрашиваться на неприятности
Игорь не ругает даже за «тпштч».
для того, чтобы желающие не могли себе нагенерировать картинки произвольного размера, можно воспользоваться модулем http_secure_link
а без него никак? чтобы один раз указать список доступных размеров и все остальные варианты отдавали 404
С готовым списком не так удобно.
Надо будет в него добавлять когда понадобятся новые типоразмеры картинок, а так просто пеняешь ссылку и всё.
мне нужно для обойного сайта. там фиксированный набор разрешений и новые появляются не так часто.
тогда само собой, пример для фиксированного размера я написал
Хороший модуль =) упоминал о нём с год назад
однако тогда народ напроч отказывался использовать front-end для ресайза картинок, предпочитая складывать мусорную статику рядом с оригинальным размером.
Хорошо, что народ отходит от этого =)

p.s. как называть nginx по-русски личное дело каждого, верно? Тпштч, например, вообще можно было услышать из уст Игоря =)
Sign up to leave a comment.

Articles