Комментарии 19
Вариант с nginx location internal не рассматривали?
+2
Порт на nginx планируем, пока без необходимости было, тут он не стоял в качестве проксировщика. По идее без проблем переписываться на nginx должно.
0
Я про то, что можно проверять наличие нужного размера и если необходимо ресайзить в php а потом делать «волшебный» редирект 'X-Accel-Redirect' и nginx сам будет отдавать картинку
0
Nginx умеет ресайзить крупать и кешировать.
0
image_filter вот тут про это писали: http://habrahabr.ru/post/157457/ оно вам не подходит?
0
Правда Ваша, но далеко не все хостят свои проекты там, где nginx
a) есть
б) собран с ngx_http_image_filter_module
в) есть возможность менять его конфиг
И вообще нет уверенности, что этот модуль кеширует то, что жмет. Больше похоже, что он это делает на лету на каждый файл.
a) есть
б) собран с ngx_http_image_filter_module
в) есть возможность менять его конфиг
И вообще нет уверенности, что этот модуль кеширует то, что жмет. Больше похоже, что он это делает на лету на каждый файл.
0
Ну да, кеш надо дополнительно настраивать. Nginx все это может сделать, но не у всех он есть.
0
Кеширует если настроить — проверено. Натсройка всего там строчек на 10, разобраться по документации очень просто.
Просто решение совершенно безгеморойное. Можно например настроить 1 сервер для кучи проектов, сделать там поддомены img.site1.com img.site2.com.
А далее обращаться как-то вот так: img.site1.com/200x400/background_big_image.jpg и все остальное разруливать яваскриптом.
Хотя конечно это все не прокатит, если речь идет о куче мелких сайтов, которые просто передаются заказчику.
Просто решение совершенно безгеморойное. Можно например настроить 1 сервер для кучи проектов, сделать там поддомены img.site1.com img.site2.com.
А далее обращаться как-то вот так: img.site1.com/200x400/background_big_image.jpg и все остальное разруливать яваскриптом.
Хотя конечно это все не прокатит, если речь идет о куче мелких сайтов, которые просто передаются заказчику.
0
1. Можно не копировать, а прокидывать симлинки. Оно и быстрее будет.
2. К имени файла картинки невредно добавлять номер версии. В тех (редких) случаях, когда вообще подразумевается замена картинок. Сходу и не придумаю, зачем это может быть нужно.
3. Как вариант, из php парсить .htaccess и писать в js. Ориентируясь на дату обновления, например. Если .htaccess моложе .js Для простоты нужный кусок .htaccess сделать include.
2. К имени файла картинки невредно добавлять номер версии. В тех (редких) случаях, когда вообще подразумевается замена картинок. Сходу и не придумаю, зачем это может быть нужно.
3. Как вариант, из php парсить .htaccess и писать в js. Ориентируясь на дату обновления, например. Если .htaccess моложе .js Для простоты нужный кусок .htaccess сделать include.
+1
Правило работает только на картинки из директории /upload/iblock/.
Битрикс?
Если так, то почему не воспользовались стандартным методом CFile::ResizeImageGet()? Он вам и картинку создаст нужных размеров и сам ее найдет при втором обращении, а при обновлении оригинала обновит и измененные изображения при новых обращениях.
0
почему бы в таком случае не переложить работу веб-сервера на js? Сгенерировать урл(ну типа там resized_image_1024_768.jpg), попытаться его загрузить(на том же js), на fail — уже отправить запрос напрямую в php и получить сгенерированную картинку?
и ещё дальше — почему бы не переложить работу по сжиманию картинки на js? В том числе и с отправкой кэша на сервер(рисково правда давать права на запись)?
И не надоест ли клиенту ждать пока его картинки подгрузятся?
PS с пережимом картинок сам сталкивался и писал небольшую функцию которая отслеживает все связи. Это была фото-галерея на собственном движке, нужно было хранить мини-картинку, побольше превьюху, ещё больше одну и оригинал. Делал всё на загрузке картинки в базу. Правда там было известно что где показывать.
и ещё дальше — почему бы не переложить работу по сжиманию картинки на js? В том числе и с отправкой кэша на сервер(рисково правда давать права на запись)?
И не надоест ли клиенту ждать пока его картинки подгрузятся?
PS с пережимом картинок сам сталкивался и писал небольшую функцию которая отслеживает все связи. Это была фото-галерея на собственном движке, нужно было хранить мини-картинку, побольше превьюху, ещё больше одну и оригинал. Делал всё на загрузке картинки в базу. Правда там было известно что где показывать.
0
В чем профит переложения на js опроса на существования картинки? Минусы понятны, плюсы — нет.
Как js должен сжимать? Сначала загрузить полную, потом пережать на клиенте и отдать нам? Грузите все, что хотите?))
Пережатие картинки происходит раз для каждого разрешения и не так долго, как можно подумать.
Как js должен сжимать? Сначала загрузить полную, потом пережать на клиенте и отдать нам? Грузите все, что хотите?))
Пережатие картинки происходит раз для каждого разрешения и не так долго, как можно подумать.
0
>> В чем профит переложения на js опроса на существования картинки?
Меньше нагрузка на веб-сервер, меньшее количество настроек, потенциально — меньше шансов запороть всю систему с помощью кривых рук.
Ну и не вижу особой разницы между получением 404 и редиректом с JS и тем же, но реализованным на стороне сервера. Хоть в случае с JS действительно будет медленнее за счёт обслуживания http.
>> Как js должен сжимать?
canvas -> scale. Очень быстро сжимает прямо на GPU. Профит в том что время серверное вообще не тратиться.
О поддержке canvas можете не заикаться — необходимый функционал работает везде, кроме ie 8(пользователи которого не оценят ваш адаптивный дизайн).
Кроме того, возможно реализовать любой «интеллектуальный» алгоритм сжатия.
>> Сначала загрузить полную, потом пережать на клиенте и отдать нам? Грузите все, что хотите?))
Если нет уже сжатой картинки — скачать полную и сжать. После этого(или вместе с этим) послать асинхронный запрос на сервер на сжатие этой картинки в кэш.
При такой схеме никаких проблем с правами на запись не будет.
Преимущества того или иного подхода нужно оценивать в реальных системах.
Я думаю если будет много графики и разных клиентов — имеет смысл распределить загрузку.
>> Пережатие картинки происходит раз для каждого разрешения и не так долго, как можно подумать.
А так, представьте себе, можно будет сжимать картинку не под определённые разрешния а под конкретно пользовательские!
Меньше нагрузка на веб-сервер, меньшее количество настроек, потенциально — меньше шансов запороть всю систему с помощью кривых рук.
Ну и не вижу особой разницы между получением 404 и редиректом с JS и тем же, но реализованным на стороне сервера. Хоть в случае с JS действительно будет медленнее за счёт обслуживания http.
>> Как js должен сжимать?
canvas -> scale. Очень быстро сжимает прямо на GPU. Профит в том что время серверное вообще не тратиться.
О поддержке canvas можете не заикаться — необходимый функционал работает везде, кроме ie 8(пользователи которого не оценят ваш адаптивный дизайн).
Кроме того, возможно реализовать любой «интеллектуальный» алгоритм сжатия.
>> Сначала загрузить полную, потом пережать на клиенте и отдать нам? Грузите все, что хотите?))
Если нет уже сжатой картинки — скачать полную и сжать. После этого(или вместе с этим) послать асинхронный запрос на сервер на сжатие этой картинки в кэш.
При такой схеме никаких проблем с правами на запись не будет.
Преимущества того или иного подхода нужно оценивать в реальных системах.
Я думаю если будет много графики и разных клиентов — имеет смысл распределить загрузку.
>> Пережатие картинки происходит раз для каждого разрешения и не так долго, как можно подумать.
А так, представьте себе, можно будет сжимать картинку не под определённые разрешния а под конкретно пользовательские!
0
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Адаптивные изображения без шаманства