Comments 19
Вариант с nginx location internal не рассматривали?
Порт на nginx планируем, пока без необходимости было, тут он не стоял в качестве проксировщика. По идее без проблем переписываться на nginx должно.
Nginx умеет ресайзить крупать и кешировать.
image_filter вот тут про это писали: http://habrahabr.ru/post/157457/ оно вам не подходит?
Правда Ваша, но далеко не все хостят свои проекты там, где nginx
a) есть
б) собран с ngx_http_image_filter_module
в) есть возможность менять его конфиг
И вообще нет уверенности, что этот модуль кеширует то, что жмет. Больше похоже, что он это делает на лету на каждый файл.
a) есть
б) собран с ngx_http_image_filter_module
в) есть возможность менять его конфиг
И вообще нет уверенности, что этот модуль кеширует то, что жмет. Больше похоже, что он это делает на лету на каждый файл.
Ну да, кеш надо дополнительно настраивать. Nginx все это может сделать, но не у всех он есть.
Кеширует если настроить — проверено. Натсройка всего там строчек на 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 и все остальное разруливать яваскриптом.
Хотя конечно это все не прокатит, если речь идет о куче мелких сайтов, которые просто передаются заказчику.
1. Можно не копировать, а прокидывать симлинки. Оно и быстрее будет.
2. К имени файла картинки невредно добавлять номер версии. В тех (редких) случаях, когда вообще подразумевается замена картинок. Сходу и не придумаю, зачем это может быть нужно.
3. Как вариант, из php парсить .htaccess и писать в js. Ориентируясь на дату обновления, например. Если .htaccess моложе .js Для простоты нужный кусок .htaccess сделать include.
2. К имени файла картинки невредно добавлять номер версии. В тех (редких) случаях, когда вообще подразумевается замена картинок. Сходу и не придумаю, зачем это может быть нужно.
3. Как вариант, из php парсить .htaccess и писать в js. Ориентируясь на дату обновления, например. Если .htaccess моложе .js Для простоты нужный кусок .htaccess сделать include.
Правило работает только на картинки из директории /upload/iblock/.
Битрикс?
Если так, то почему не воспользовались стандартным методом CFile::ResizeImageGet()? Он вам и картинку создаст нужных размеров и сам ее найдет при втором обращении, а при обновлении оригинала обновит и измененные изображения при новых обращениях.
почему бы в таком случае не переложить работу веб-сервера на js? Сгенерировать урл(ну типа там resized_image_1024_768.jpg), попытаться его загрузить(на том же js), на fail — уже отправить запрос напрямую в php и получить сгенерированную картинку?
и ещё дальше — почему бы не переложить работу по сжиманию картинки на js? В том числе и с отправкой кэша на сервер(рисково правда давать права на запись)?
И не надоест ли клиенту ждать пока его картинки подгрузятся?
PS с пережимом картинок сам сталкивался и писал небольшую функцию которая отслеживает все связи. Это была фото-галерея на собственном движке, нужно было хранить мини-картинку, побольше превьюху, ещё больше одну и оригинал. Делал всё на загрузке картинки в базу. Правда там было известно что где показывать.
и ещё дальше — почему бы не переложить работу по сжиманию картинки на js? В том числе и с отправкой кэша на сервер(рисково правда давать права на запись)?
И не надоест ли клиенту ждать пока его картинки подгрузятся?
PS с пережимом картинок сам сталкивался и писал небольшую функцию которая отслеживает все связи. Это была фото-галерея на собственном движке, нужно было хранить мини-картинку, побольше превьюху, ещё больше одну и оригинал. Делал всё на загрузке картинки в базу. Правда там было известно что где показывать.
В чем профит переложения на js опроса на существования картинки? Минусы понятны, плюсы — нет.
Как js должен сжимать? Сначала загрузить полную, потом пережать на клиенте и отдать нам? Грузите все, что хотите?))
Пережатие картинки происходит раз для каждого разрешения и не так долго, как можно подумать.
Как js должен сжимать? Сначала загрузить полную, потом пережать на клиенте и отдать нам? Грузите все, что хотите?))
Пережатие картинки происходит раз для каждого разрешения и не так долго, как можно подумать.
>> В чем профит переложения на js опроса на существования картинки?
Меньше нагрузка на веб-сервер, меньшее количество настроек, потенциально — меньше шансов запороть всю систему с помощью кривых рук.
Ну и не вижу особой разницы между получением 404 и редиректом с JS и тем же, но реализованным на стороне сервера. Хоть в случае с JS действительно будет медленнее за счёт обслуживания http.
>> Как js должен сжимать?
canvas -> scale. Очень быстро сжимает прямо на GPU. Профит в том что время серверное вообще не тратиться.
О поддержке canvas можете не заикаться — необходимый функционал работает везде, кроме ie 8(пользователи которого не оценят ваш адаптивный дизайн).
Кроме того, возможно реализовать любой «интеллектуальный» алгоритм сжатия.
>> Сначала загрузить полную, потом пережать на клиенте и отдать нам? Грузите все, что хотите?))
Если нет уже сжатой картинки — скачать полную и сжать. После этого(или вместе с этим) послать асинхронный запрос на сервер на сжатие этой картинки в кэш.
При такой схеме никаких проблем с правами на запись не будет.
Преимущества того или иного подхода нужно оценивать в реальных системах.
Я думаю если будет много графики и разных клиентов — имеет смысл распределить загрузку.
>> Пережатие картинки происходит раз для каждого разрешения и не так долго, как можно подумать.
А так, представьте себе, можно будет сжимать картинку не под определённые разрешния а под конкретно пользовательские!
Меньше нагрузка на веб-сервер, меньшее количество настроек, потенциально — меньше шансов запороть всю систему с помощью кривых рук.
Ну и не вижу особой разницы между получением 404 и редиректом с JS и тем же, но реализованным на стороне сервера. Хоть в случае с JS действительно будет медленнее за счёт обслуживания http.
>> Как js должен сжимать?
canvas -> scale. Очень быстро сжимает прямо на GPU. Профит в том что время серверное вообще не тратиться.
О поддержке canvas можете не заикаться — необходимый функционал работает везде, кроме ie 8(пользователи которого не оценят ваш адаптивный дизайн).
Кроме того, возможно реализовать любой «интеллектуальный» алгоритм сжатия.
>> Сначала загрузить полную, потом пережать на клиенте и отдать нам? Грузите все, что хотите?))
Если нет уже сжатой картинки — скачать полную и сжать. После этого(или вместе с этим) послать асинхронный запрос на сервер на сжатие этой картинки в кэш.
При такой схеме никаких проблем с правами на запись не будет.
Преимущества того или иного подхода нужно оценивать в реальных системах.
Я думаю если будет много графики и разных клиентов — имеет смысл распределить загрузку.
>> Пережатие картинки происходит раз для каждого разрешения и не так долго, как можно подумать.
А так, представьте себе, можно будет сжимать картинку не под определённые разрешния а под конкретно пользовательские!
Sign up to leave a comment.
Адаптивные изображения без шаманства