Можем ли мы использовать хранилище BLOB-объектов Azure для ImageCache ImageResizer?

В основном мы используем рекомендуемую облачную архитектуру, где исходные изображения хранятся в хранилище BLOB-объектов Azure, Imageresizer работает в службе приложений Azure, а Azure CDN - это уровень CDN.

Тем не менее у нас возникла проблема с ImageResizer v3, слоты развертывания службы приложений Azure и DiskCache.

Мы используем промежуточный слот в нашей службе приложений Azure, чтобы предотвратить прерывания. Мы также используем плагин DiskCache. Без какой-либо конфигурации imagecache записывается в D: \ home \ site \ wwwroot \ imagecache \, который зависит от слота.

Это порождает две проблемы:

  1. Когда мы меняем местами слоты, используемый кеш изображений устарел, и многие изображения будут отсутствовать.
  2. У нас всегда есть устаревший кэш изображений, занимающий дисковое пространство в нашем плане обслуживания приложений, наш консультант в Microsoft рекомендовал использовать хранилище BLOB-объектов вместо виртуальной локальной файловой системы для DiskCache.

Я заметил, что нет BlobCachePlugin или S3CachePlugin, и мне было интересно, есть ли для этого веская причина.

Мои вопросы:

  1. Есть ли причина не хранить кэш изображений в хранилище BLOB-объектов Azure с помощью настраиваемого плагина BlobStorageCachePlugin, реализующего интерфейс ICache?
  2. Если есть веская причина, какую альтернативную архитектуру вы посоветуете, чтобы избежать проблем со слотами развертывания?

azure azure-app-service-plans imageresizer imageresizer-diskcache
person Wilgert    schedule 12.12.2016    source источник

Ответы (2)


arrow_upward
1
arrow_downward

Кеши должны иметь низкую задержку. Помещение кеша в хранилище BLOB-объектов приведет к ужасной производительности даже при обращении к кешу, вероятно, добавив 800-1800 мс на запрос. Если бы сервер Redis был доступен, есть способы улучшить его работу, но он все равно не будет работать так же хорошо, как при использовании хранилища с низкой задержкой.

Решения проблемы холодного кеша:

  1. Разогрейте промежуточный слот, дублируя к нему реальные запросы (идеальная ситуация, поскольку он также нагревает кеши, не относящиеся к IR).
  2. Если это невозможно, то вы можете подумать о каком-то запланированном копировании между imagecache папками на каждом сервере, которое «только добавляет» файлы. Не пытайтесь изменять или удалять файлы или каталоги, которые активно обслуживаются.
  3. Используйте распределенную файловую систему с малой задержкой или общий сетевой диск с малой задержкой. Однако измерьте задержку, потому что это будет проблемой, если у вас нет очень хорошего сетевого соединения между серверами. Существуют хранилища BLOB-объектов, которые могут быть достаточно быстрыми для использования для кэширования, но обычно только тогда, когда вы управляете ими самостоятельно, чтобы обеспечить низкую задержку.

Это означает, что вы не сможете включить autoClean для автоматической очистки записей кеша; настроить мониторинг использования диска.

person Lilith River    schedule 12.12.2016
comment
Согласно azurespeed.com, задержка BlobStorage на самом деле не так уж плоха (около 40 мс с пиковым значением 400 мс). ). Тем более, что наша служба приложений находится в том же центре обработки данных / регионе, что и BlobStorage. Есть ли у вас практический опыт, свидетельствующий об обратном? - person Wilgert; 13.12.2016
comment
Я никогда не видел задержки 40 мс, может быть, 100 мс в хороший день. если у вас хорошая задержка, вы можете посмотреть на это сторонние пакеты nuget. Но разве для попаданий в кеш можно добавить даже 40 мс? - person Lilith River; 14.12.2016
comment
Я не уверен, действительно ли это актуальное приложение для размещения решений в Службе приложений Azure (именно о том, что беспокоило автора вопроса). Наличие гигабайт кэшированных изображений на диске службы приложений Azure - это не то, что рекомендует команда Azure. Веб-приложения Azure не оптимизированы для хранения. Рекомендуется хранить весь статический контент в службе хранилища Azure. Задержка не должна быть такой высокой, как упоминалось (если ваше приложение, конечно, также находится в Azure), а также позже статический контент в любом случае должен кэшироваться на стороне клиента. - person Aleksanderis; 24.07.2019
comment
@LilithRiver, не могли бы вы расширить свой комментарий о отключении autoClean? Какие негативные последствия произойдут, если бы это было включено? - person ajbeaven; 03.09.2019

arrow_upward
0
arrow_downward

Если у вас есть CDN, установленный перед вашим веб-приложением, нужен ли вам вообще плагин DiskCache (или запрошенное кэширование хранилища BLOB-объектов)?

После того, как изображение было обработано веб-приложением, оно затем кэшируется одним из пограничных серверов CDN, так какой цели будет служить его кэширование в хранилище веб-приложения / BLOB-объектов?

person ADMX    schedule 10.01.2017
comment
Что ж, у нас есть пользователи со всего мира в сочетании с более чем 300 000 изображений разных размеров. Наша частота попаданий в кеш CDN недостаточно высока, чтобы полагаться только на нее. Кроме того, изменение размера изображений происходит очень медленно (в считанные секунды), поэтому мы лучше также сохраняем версию с измененным размером в локальном кеше. p.s. Я не знаю, знаете ли вы, но если что-то находится в кеше на каком-то пограничном сервере, оно все равно загружается из источника с любого другого пограничного сервера. - person Wilgert; 11.01.2017
comment
Мы также попробовали решение CDN. К сожалению, проблема с CDN заключается в том, что существует большая дополнительная проблема с авторизацией (в случае, если ваши изображения доступны только авторизованным пользователям). Кажется, что можно настроить некоторую авторизацию на CDN, но только на уровне Premium, и это нетривиальное решение. Если ImageResizer может кэшировать изображения в хранилище BLOB-объектов напрямую, вся авторизация может выполняться на сервере. Т.е. Хранилище BLOB-объектов не является общедоступным и доступно только при наличии строки подключения с ключами / секретами / и т. Д. Практически так же, как ImageResizer обращается к исходным изображениям. - person Aleksanderis; 24.07.2019