2011-01-10 1 views
2

Мы находимся в процессе перемещения приложения по помещению в облако Azure. Внутренние корпоративные пользователи регулярно загружают полноразмерные изображения через интерфейс администратора на наш сайт (теперь они будут отправлены в хранилище Azure blob). Сайт отвечает за создание правильных размеров изображений при их запросе. Итак, что происходит прямо сейчас (в среде помещения):Программирование против Azure/CDN

1) Пользователь загружает полный размер файла.

2) Когда меньшая версия запрашивается с помощью обработчика GetImage HTTP (т. Е. http://www.site.com/GetImage.aspx?imageid=15&height=100&width=100), обработчик проверяет, была ли ранее создана версия этого изображения в этом размере. Если это так, он записывает его непосредственно в поток Response. Если нет, потребуется несколько секунд, чтобы изменить размер, сохранить его в каталоге «/ iamges/cache» и записать измененное изображение в поток ответов.

3) В следующий раз, когда этот файл запрашивается в этом размере, он возвращает ранее созданное изображение.

Так что я хочу, чтобы реализовать один и тот же тип механизма с использованием Azure Blob и хранения, но у меня есть несколько проблем:

1) Я просто не могу проверить, чтобы увидеть, если пятно существует. Мне нужно сначала загрузить blob, а затем вызвать FetchAttributes, чтобы увидеть, вызывает ли это исключение. Однако, это действительно загружает изображение. Разве это не удваивает количество запросов на изображения (один, чтобы увидеть, существует ли он, а другой - пользователю)?

2) Предположим, что изображение не существует в размере, в котором я нуждаюсь (т. Е. Blob /images/cache/image_15_100_100.jpg не существует - идентификатор № 15, 100x100 пикселей). Таким образом, я ударил запрос на CDN один раз, чтобы узнать, существует ли он. Теперь мне нужно скачать возможно 5-10 МБ полноразмерного изображения (в отличие от чтения его с нашей файловой системы на месте, которая быстрая), загрузите это 5-10 МБ изображения в память, измените размер и повторно загрузите его в CDN. Это кажется трудоемким, особенно когда я могу получить 10-15 изображений по одному запросу.

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

+0

Возможны ли заданные размеры размера изображения или они полностью произвольны? – Omar

+0

Они несколько предопределены на данный момент, но требования к бизнесу утверждают, что мы должны иметь возможность изменять размер до любого размера на лету. Я думал о предварительной загрузке их в правильные размеры уже. :) – Scott

+0

Почему бы не использовать Azure SQL для хранения Blobs и метаданных, включая ссылки на последнюю загрузку изображения определенного размера, если кто-то из одной сети запросил изображения, которые вы могли бы получить через локальную сеть, кеш локально и т. Д.? У вас остались бы загруженные изображения – Lloyd

ответ

6

ОК, я думаю, здесь много чего происходит. Мой ответ основан на следующих предположениях:

  • Окончательное использование этих изображений является отображаться на сайте
  • Сайт упоминалось выше работает на Azure
  • Вы хотите использовать CDN для ускорить доступ к изображениям
  • Вы используете клиент Хранения в системе .Net библиотеки

Если y этих предположений неверны, дайте мне знать, и я отредактирую свой ответ соответствующим образом.

  1. Вы правы, нет встроенного метода в клиентской библиотеке .Net, которая позволяет вам проверить, существует ли blob. Но, делая .FetchAttributes(), это фактически не загружает изображение, оно просто пытается retrieve the header information (так же, как при перечислении всех блоков в контейнере), капли фактически не загружаются, пока вы не вызовете один из методов .DownloadX() ,

  2. На вашем серверном коде нет необходимости говорить, чтобы использовать любую из функций CDN. Он должен просто разговаривать с вашими изображениями в хранилище blob, как будто это какой-то старый blob. Единственный раз, когда вам нужно использовать URL-адреса CDN, - это когда вы указываете путь к изображениям на отображаемой странице.

  3. Вы не хотите, чтобы на вашем веб-сайте вы возвращали поток изображения, вы хотите, чтобы он указывал URL-адрес на CDN, который содержит изображение. CDN сможет справиться с гораздо большей нагрузкой, чем любой веб-сайт, который вы можете создать. Затем веб-сайт может проверить, существует ли blob, если это так, просто верните URL-адрес. Если он не загружает полное изображение, измените его размер, сохраните его и верните URL-адрес. Хотя доступ к изображению из хранилища blob не так быстр, как чтение его с локального диска, все равно довольно быстро, особенно для файлов < 10MB, как вы говорите.

  4. Предположительно, где-то кто-то указывает, где и какие изображения будут использоваться на вашем сайте. Не могли бы вы захватить это и создать изображение с измененным размером?