Программирование на Azure / CDN - PullRequest
2 голосов
/ 10 января 2011

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

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

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

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

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

1) Я не могу просто проверить, существует ли капля. Сначала я должен загрузить большой двоичный объект, а затем вызвать FetchAttributes, чтобы увидеть, вызывает ли оно исключение. Тем не менее, делая это на самом деле загружает изображение. Так разве это не удваивает количество запросов на изображения (один, чтобы увидеть, существует ли он, и другой, чтобы показать пользователю)?

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

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

1 Ответ

6 голосов
/ 10 января 2011

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

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

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

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

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

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

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

...