Кэширование изображений против.обработка изображений в PHP и S3
-
20-08-2019 - |
Вопрос
Вот в чем дело.Прямо сейчас у меня есть веб-сайт электронной коммерции, где люди могут присылать много фотографий своей продукции.Все изображения хранятся на Amazon S3.Когда нам нужна миниатюра или что-то в этом роде, я проверяю S3, есть ли она в наличии.Если нет, я обрабатываю его, отправляю на S3 и отображаю в браузере.Все миниатюры разного размера сохраняются на S3, и проверка доступности миниатюр по каждому запросу требует больших затрат.Боюсь, я заплачу много, как только сайт начнет привлекать больше внимания (если он получит...).
Размышляя об альтернативах, я думал о том, чтобы хранить в S3 только исходные изображения и обрабатывать изображения «на лету» по каждому запросу.Я предполагаю, что таким образом я бы сэкономил на использовании процессора, но я не проводил никаких тестов, чтобы увидеть, как далеко я могу зайти.Дело в том, что я не стал бы тратить деньги на запросы и хранение большего количества изображений на S3 и мог бы кэшировать все в браузере пользователя.Я знаю, что это не так безопасно, поэтому я задаю этот вопрос здесь.
Что вы думаете?Как, по-твоему, я смогу это решить?
Решение
Сохраняйте локальный кеш:
- Какие изображения есть в S3
- Кэш самых популярных изображений
Тогда в обоих случаях у вас есть локальная ссылка.Если изображения нет в локальном кеше, вы можете проверить локальный кеш, чтобы узнать, находится ли оно в S3.Экономит трафик S3 для самых популярных элементов и снижает задержку при проверке S3 на предмет элемента, которого нет в локальном кеше.
Другие советы
Я бы изменил размер во время загрузки и сохранил всю версию в S3.
Например, если у вас есть изображение большего размера (1200x1200 ~ 200 КБ) и вы создаете 3 версии с измененным размером (300x300, 120x120 и 60x60), вы добавляете только около 16% или 32 КБ (для моего тестового изображения YMMV).Допустим, вам нужно сохранить миллион изображений;это примерно на 30 ГБ больше, или дополнительно 4,5 доллара в месяц.Flickr сообщил, что у него 2 миллиарда изображений (в 2007 году), что составляет около 9 тысяч долларов дополнительно в месяц, не так уж и плохо, если вы такой большой.
Еще одним важным преимуществом является то, что вы сможете использовать CloudFront от Amazon.
Если вы передаете проксирование с S3 своим клиентам (что, похоже, вы и делаете), рассмотрите две оптимизации:
- Во время загрузки сразу измените размер изображений и загрузите их как пакет (tar, XML и т. д.).
- Кэшируйте эти пакеты изображений на своих внешних узлах.
«Пакет изображения» уменьшит количество операций PUT/GET/DELETE, которые в S3 не бесплатны.Если у вас 4 размера изображения, вы уменьшите его на 4.
Кэш еще больше уменьшит трафик S3, поскольку я полагаю, что рабочий процесс обычно заключается в просмотре миниатюры -> щелкните ее, чтобы увеличить изображение.
Кроме того, вы можете реализовать кеш «горячих изображений», который активно передается на ваши веб-узлы, поэтому он предварительно кэшируется, если вы используете кластер.
Кроме того, я не рекомендую использовать Slicehost<->S3.Транзитные расходы вас убьют.Вам действительно следует использовать EC2, чтобы сэкономить массу трафика (денег!!).
Если вы не проксируете, а передаете своим клиентам URL-адреса S3 для изображений, вам определенно понадобится предварительная обработка всех ваших изображений.Тогда вам не нужно их проверять, а просто передать URL-адрес своему клиенту.
Каждый раз повторная обработка изображений обходится дорого.Вы обнаружите, что если предположить, что размеры всех изображений изменены, объем усилий на ваших веб-узлах снизится, и все ускорится.Это особенно верно, поскольку вы не отправляете несколько запросов S3.