Кэширование выходных стратегий обработчика изображений - PullRequest
1 голос
/ 16 ноября 2011

Во-первых, я ценю, что этот вопрос можно рассматривать как субъективный, но я твердо верю, что на мой вопрос должен быть и, вероятно, окончательный ответ.

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

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

например,

using (MemoryStream ms = new MemoryStream())
{
    imageEditor.Image.Save(ms, imageFormat);
    // Add the file to the cache.
    context.Cache.Insert(key, 
        ms.ToArray(), 
        new System.Web.Caching.CacheDependency(path)
        );
    imageEditor.Dispose();

    // Set the context headers and serve.
    SetHeaders(ms.GetHashCode(), context, responseType);
    context.Response.BinaryWrite(ms.ToArray());
}

Это имеет свои недостатки, хотя.

  1. Каждый раз, когда рабочий процесс пула приложений перезапускается (по умолчанию каждые 1740 минут), мы будемпотерять все, что находится в кеше.
  2. Если изображений много, мы можем быть перегружены системной памятью и вызвать исключение нехватки памяти.(Предотвращает ли IIS это, перерабатывая пул приложений, если использование достигает определенного уровня?)

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

  1. Мы больше не можем отслеживать исходный файл, поэтому, если кто-то загрузит новое изображение с тем же именемнаши измененные изображения будут неправильными.
  2. Файловый сервер со временем загрязняется тысячами изображений
  3. Чтение файла происходит медленнее, чем чтение из памяти.Особенно, если вы читаете несколько файлов.

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

Ответы [ 3 ]

1 голос
/ 16 ноября 2011

У нас есть похожая система на моем сайте.Что касается ваших возражений против системы кеширования файлов:

1,2) На моем сайте у меня есть один класс, через который проходит все сохранение / загрузка файлов.Вы могли бы реализовать что-то подобное, которое очищает все кэшированные изображения с измененным размером каждый раз, когда пользователь загружает новое изображение.Если вы называете файлы предсказуемым образом, это не сложно сделать.Если вас беспокоит пространство хранения, вы можете реализовать что-то, чтобы удалить все кэшированные изображения с последней датой доступа, которая слишком старая.

3) Это зависит от того, как работают ваши сайты.На моем сайте огромное количество изображений, поэтому невозможно сохранить их все в памяти.Если на вашем сайте меньше изображений, это может быть лучшим решением.

1 голос
/ 16 ноября 2011

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

0 голосов
/ 16 ноября 2011
Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...