Постоянное кэширование ASP.NET (стиль «отложенной загрузки»?) - PullRequest
2 голосов
/ 29 июня 2009

У меня возникли проблемы с тем, чтобы заставить мой кеш работать так, как я хочу.

Проблема: Процесс получения запрошенных данных занимает очень много времени. При использовании стандартного кэширования ASP.NET некоторые пользователи получат «хит» извлечения данных. Это не приемлемо.

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

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

Ответы [ 6 ]

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

Есть инструменты, которые делают это, например, Microsoft ISA Server (может быть немного дороже / излишне).

Вы можете кэшировать его в памяти, используя Enterprise Libary Caching. Пусть ваши пользователи читают из кэша и имеют другие страницы, которые обновляют кэш, эти другие страницы следует вызывать так регулярно, как вам нужно, чтобы данные обновлялись.

1 голос
/ 02 сентября 2012

Вы можете сделать это довольно легко с помощью классов Cache и Timer, встроенных в .NET. Таймер работает в отдельном потоке.

И я на самом деле написал очень маленькую библиотеку-оболочку под названием WebCacheHelper , которая предоставляет эту функциональность в перегруженном конструкторе. Библиотека также служит строго типизированной оболочкой для объекта Cache.

Вот пример того, как вы могли бы сделать это ...

public readonly static WebCacheHelper.Cache<int> RegisteredUsersCount = 
  new WebCacheHelper.Cache<int>(new TimeSpan(0, 5, 0), () => GetRegisteredUsersCount()); 

Это имеет ленивый аспект загрузки, где GetRegisteredUsersCount() будет выполняться в вызывающем потоке в момент первого доступа к RegisteredUsersCount. Однако после этого он выполняется каждые 5 минут в фоновом потоке. Это означает, что единственным пользователем, который будет оштрафован за медленное время ожидания, будет самый первый пользователь.

Тогда получить значение так же просто, как сослаться на RegisteredUsersCount.Value.

1 голос
/ 17 ноября 2009

Я создал свое собственное решение со словарем / хэш-таблицей в памяти как дубликат реального кеша. Когда при запросе объекта из кеша пришел вызов метода, а его там не было, но он присутствовал в памяти, был сохранен сохраненный в памяти объект и запущен новый поток для обновления объекта как в памяти, так и в кеше с использованием метода делегата.

1 голос
/ 29 июня 2009

Вы можете прослушать, когда кэшированный элемент будет удален и обработать,

public void RemovedCallback(String k, Object v, CacheItemRemovedReason r)
{
    // Put Item Back IN Cache, ( so others can use it until u have finished grabbing the new data)

    // Spawn Thread to Go Get Up To Date Data

    // Over right Old data with new return... 
} 

в глобальном asax

protected void Application_Start(object sender, EventArgs e)
{
     // Spawn worker thread to pre-load critical data
}

Ооо ... Я понятия не имею, если это лучшая практика, я просто подумала, что это будет здорово ~ Удачи ~

0 голосов
/ 08 июля 2009

В этой ситуации я использую CacheTable в db для кэширования последних данных и запускаю фоновое задание (со службой Windows. В общей среде вы также можете использовать потоки), которое обновляет данные в таблице.

Существует очень мало возможностей показать пользователю пустой экран. Я устраняю это, также кэшируя через кеш asp.net на 1 минуту.

Не знаю, если это плохой дизайн, но он отлично работает без проблем на часто используемом веб-сайте.

0 голосов
/ 08 июля 2009

Да, вы можете просто кэшировать наиболее часто используемые данные при запуске вашего приложения, но это все равно означает, что первый пользователь, который сработает, «примет удар», как вы говорите (при условии, конечно, inproc cache).

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