celery — это хорошо, но в случае если он будет нужен только для картинок — то проще обойдись чем, то самописным. А если возникнет потребность обрабатывать еще что-либо в фоне — то тогда проще переписать велосипед на celery.
Тем более, что при использовании celery потребуется править код сайта — добавлять задачу при загрузке картинки и добавлять задачу при удалении(смены) картинки.
Почитал. Да. Решение с nginx круче и серьезнее. Мне нравится. Пожалуй время затраченное на пост и на демон, стоит того, что бы увидеть ваш комментарий. Не знал о этом модуле. Теперь знаю)
да нет… крутить систему мониторинга ради одного демона — соглашусь как-то странно, но если она уже есть и демон трудится не один? то почему бы и нет?)
> таким образом, чтобы эти копии можно было найти и удалить при удалении оригинала.
так в этом то и проблема? каким образом нужно хранить ресайзы, что бы их легко можно было найти и удалить?
алгоритм то тут немного не быстрый. Сначала создается папка с новым размером. Демон ее хватает и работает.
А пока изменить во вью ссылку на новые изображения, пока закомитеть это, проверить, выложить — пройдет достаточно времени, что бы создались нужные изображения.
есть лента публикаций. У каждой публикации есть заглавная картинка. Создаем страницу анонс новостей за прошлый месяц и получаем 100 сообщений с маленькими картинками.
По вашему, зачем их ресайзить??? Вы предлагаете их выдать по первому варианту? вместо 1 мб страницы выдастся 100 мб? Действительно спорный вопрос.
Неплохо. Только будет один минус — если есть страница, где выводится много различных превьюшек, то сайт призадумается при генерации этих изображений (если это после очистки кэша ресайзов). Хоть такой вариант маловероятен, но тем не менее…
Т.е ваш вариант неплох. А чем плох мой? Т.е какие именно недостатки у него?
демон работает в фоне. Пока создаются новые размеры — можно публикацию написать
Хотя вы правы — в этом случае (хоть он и маловероятен 100 млн изображений) — я бы создал инструменты по созданию новых размеров и скрипт конвертации выполнился бы пакетно.
мое решение не совсем «на лету», демон отработает до захода пользователя
ваше решение имеет недостаток — слишком много вводить сущностей — и очередь, и обработчик очереди, и приниматель запросов на получение картинки.
3. не совсем понял что значит «Не всегда размеры, бывают подходящими под задачу»,
допустим вы выделили размеры xs — 100x100 s -200x200 l — 800x600 xl — 1200x1600 (например). а нам нужно вывести картинку размером 300х300, конечно мы не сильно пострадаем, если выведем L (800x600) и сократим, но тем не менее, это не хорошо.
4. Добавить логику на проверку размерности (т.е что нафиг, а что нет) — это хорошо, но как решать проблему смены изображений у публикации. Когда удаляется оригинальная картика, то как найти отресазенные?
про недостатки
1. это не крон
2. Так рассуждать — вообще демонов не писать. Есть же системы мониторинга.
3. увы)
Вы наверное недопоняли проблему удаление неиспользуемых изображений. Если меняется изображение у публикации, то старое (там где оно загружено) удаляется, а новое создается. Как удалить созданные ресайзы для этого изображения?
в django в разделе Djcelery / Tasks нет кнопки добавить задачу.
Тем более, что при использовании celery потребуется править код сайта — добавлять задачу при загрузке картинки и добавлять задачу при удалении(смены) картинки.
> таким образом, чтобы эти копии можно было найти и удалить при удалении оригинала.
так в этом то и проблема? каким образом нужно хранить ресайзы, что бы их легко можно было найти и удалить?
А пока изменить во вью ссылку на новые изображения, пока закомитеть это, проверить, выложить — пройдет достаточно времени, что бы создались нужные изображения.
По вашему, зачем их ресайзить??? Вы предлагаете их выдать по первому варианту? вместо 1 мб страницы выдастся 100 мб? Действительно спорный вопрос.
Т.е ваш вариант неплох. А чем плох мой? Т.е какие именно недостатки у него?
Хотя вы правы — в этом случае (хоть он и маловероятен 100 млн изображений) — я бы создал инструменты по созданию новых размеров и скрипт конвертации выполнился бы пакетно.
ваше решение имеет недостаток — слишком много вводить сущностей — и очередь, и обработчик очереди, и приниматель запросов на получение картинки.
допустим вы выделили размеры xs — 100x100 s -200x200 l — 800x600 xl — 1200x1600 (например). а нам нужно вывести картинку размером 300х300, конечно мы не сильно пострадаем, если выведем L (800x600) и сократим, но тем не менее, это не хорошо.
4. Добавить логику на проверку размерности (т.е что нафиг, а что нет) — это хорошо, но как решать проблему смены изображений у публикации. Когда удаляется оригинальная картика, то как найти отресазенные?
про недостатки
1. это не крон
2. Так рассуждать — вообще демонов не писать. Есть же системы мониторинга.
3. увы)