Кэширование изображений и обработка изображений в PHP и S3 - PullRequest
4 голосов
/ 27 июня 2009

Вот эта вещь. Прямо сейчас у меня есть этот веб-сайт электронной коммерции, где люди могут отправлять множество фотографий для своих продуктов. Все изображения хранятся на Amazon S3. Когда нам нужен эскиз или что-то в этом роде, я проверяю S3, если он есть. Если нет, я обрабатываю один и отправляю его на S3 и отображаю в браузере. Миниатюры каждого размера сохраняются на S3, и проверка наличия миниатюр при каждом запросе требует больших затрат. Боюсь, я заплачу много, как только сайт начнет привлекать больше внимания (если он получит ...).

Думая об альтернативах, я думал о том, чтобы сохранить только оригинальные изображения на S3 и обрабатывать изображения на лету при каждом запросе. Я полагаю, что таким образом я бы использовал загрузку процессора, но я не сделал никаких тестов, чтобы посмотреть, как далеко я смогу зайти. Дело в том, что я не стал бы тратить деньги, делая запросы и сохраняя больше изображений на S3, и я мог кэшировать все в браузере пользователя. Я знаю, что это не так безопасно, поэтому я привожу этот вопрос здесь.

Что ты думаешь? Как вы думаете, я мог решить это?

Ответы [ 3 ]

5 голосов
/ 27 июня 2009

Я бы изменил размер во время загрузки и сохранил бы всю версию в S3.

Например, если у вас есть увеличенное изображение (1200x1200 ~ 200kb) и вы создаете версию с 3 размерами (300x300, 120x120 и 60x60), вы добавляете только около 16% или 32kb (для моего тестового изображения YMMV). Допустим, вам нужно хранить миллион изображений; это примерно на 30 ГБ больше, или 4,5 доллара в месяц. Flickr сообщил, что у него есть 2 миллиарда изображений (в 2007 году), что составляет ~ 9 тысяч долларов в месяц, что не так уж плохо, если вы такой большой.

Еще одним важным преимуществом является то, что вы сможете использовать Amazon CloudFront.

3 голосов
/ 27 июня 2009

Если вы используете прокси-сервер S3 для своих клиентов (что звучит так, как вы), рассмотрите две оптимизации:

  1. Во время загрузки измените размер изображений и загрузите их как пакет (tar, XML и т. Д.)
  2. Кэшируйте эти пакеты изображений на ваших интерфейсных узлах.

Пакет изображений уменьшит количество операций PUT / GET / DELETE, которые не являются свободными в S3. Если у вас есть 4 размера изображения, вы уменьшите на 4.

Кэш еще больше сократит трафик S3, поскольку я считаю, что рабочий процесс обычно отображается в виде миниатюры -> щелкните по ней, чтобы увеличить изображение.

Кроме того, вы можете реализовать кэш «горячих изображений», который активно отправляется на ваши веб-узлы, поэтому он предварительно кэшируется, если вы используете кластер.

Кроме того, я не рекомендую использовать Slicehost <-> S3. Транспортные расходы убьют вас. Вы должны действительно использовать EC2, чтобы сэкономить тонну пропускной способности (Деньги !!).

Если вы не используете прокси-сервер, а передаете своим клиентам S3 URL-адреса для изображений, вам определенно потребуется предварительно обработать все ваши изображения. Тогда вам не нужно проверять их, а просто передать URL-адрес вашему клиенту.

Повторная обработка изображений каждый раз является дорогостоящей. Вы обнаружите, что если вы можете предположить, что размер всех изображений изменен, количество усилий на ваших веб-узлах уменьшится, и все ускорится. Это особенно верно, поскольку вы не запускаете несколько запросов S3.

2 голосов
/ 27 июня 2009

Хранить локальный кеш:

  1. Какие изображения в S3
  2. Кеш самых популярных изображений

Тогда в обоих случаях у вас есть местная ссылка. Если изображение не находится в локальном кэше, вы можете проверить локальный кэш, чтобы увидеть, находится ли он в S3. Экономит трафик S3 для ваших самых популярных предметов и экономит время ожидания при проверке S3 на предмет, отсутствующий в локальном кэше.

...