Реализация кэширования asp.net для популярного контента

Question

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

пример кода:

public class ContentCachingExample
{
    private static DateTime _lastRequestTime;
    private static MyContent _cachedContent;

    private static MyContent GetContent()
    {
        // compare dates - content will be re-retrieved from DB once a day.
        if (DateTime.Now.Date> _lastRequestTime.Date) 
        {
            _lastRequestTime = DateTime.Now;
            _cachedContent = GetContentFromDb();
        }
        return _cachedContent;
    }

    private static MyContent GetContentFromDb()
    {
        // get content from DB
    }

    public class MyContent
    {
        public string Property1 { get; set; }
        public int Property2 { get; set; }
    }
 }

Answer 1

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

Не забудьте подумать об истечении срока действия кэша, что если этот популярный контент изменится? Как долго, прежде чем вы используете, увидеть новый контент? Вы получаете значительное повышение производительности для времени кеширования, намного меньшего, чем 24 часа, если у вас есть просмотр страницы в секунду, то время кеширования в 1 минуту сэкономит вам 59 поездок в БД и означает, что, если страница будет разбита, у вас есть (маленький) шанс на выживание.

Если вы используете MS-SQL, есть способы сделать недействительными кэши , если строка или таблица изменятся

Вы также можете захотеть изучить кэширование вывода , если вы используете ASP.NET, это позволяет вам кэшировать результат со страницы или элемента управления на основе параметров URL. Это позволяет вам сохранять нагрузку на ЦП веб-сервера, а также на загрузку БД с помощью кэширования.

попробуйте использовать System.Web.Cache

private MyContent GetContent(){
   MyContent content = Cache[GetContentCacheKey()];
   if(content == null) {
     content = GetContentFromDb();
     Cache.Add(GetContentCaceKey(), content, null, DateTime.Now.AddHours(1), 
          Cache.NoSlidingExpiration, CacheItemPriority.High, null);
   }
   return content;
}

Answer 2

То, что вы делаете, является распространенным паттерном.

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

Дэвид упомянулSystem.Web.Cache

Существует также Блоки кэширования корпоративной библиотеки

Однако, если вам нужны только текущие возможности вашего кода, то у вас все в порядке.

Answer 3

Это называется преждевременной оптимизацией.Вы пытаетесь решить проблему, о которой вы (предположительно) не знаете.

Это часто вредно.Например, если у вас сейчас плохая производительность, это может быть связано с тем, что вы ограничены в памяти: например, при запуске SQL Server и IIS на одной машине, и это слишком много.В этом случае стратегия caching-DB-content не помогла бы, а усугубила бы ситуацию.

Если запрос к базе данных занимает много времени для извлечения (так как измеряется напрямую поВы и подтвердили , что пользователю ждать слишком долго: вы действительно должны выполнить эти два шага), тогда вы можете рассмотреть что-то, как вы предложили.Вы захотите заглянуть в объект ASP.NET Cache, а не изобретать его самостоятельно.Быстрый гугл открывает эту страницу http://msdn.microsoft.com/en-us/library/aa478965.aspx, что может быть хорошей отправной точкой.

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