Стратегии «предварительного прогрева» кэша ASP.NET

Question

У меня есть веб-приложение ASP.NET MVC 3 / .NET, которое в значительной степени управляется данными, в основном вокруг концепции "местоположений" (Нью-Йорк, Калифорния и т. Д.).

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

Например:

public ICollection<Location> FindXForX(string x)
{
   var result = _cache.Get(x.ToKey()) as Locaiton; // try cache

   if (result == null) {
      result = _repo.Get(x.ToKey()); // call db
      _cache.Add(x.ToKey(), result); // add to cache
   }

   return result;
}

Но я не хочу, чтобы незадачливый первый пользовательожидание этого вызова базы данных.

Вызов базы данных может занять от 40 до 60 секунд, что значительно превышает время ожидания по умолчанию для запроса ASP.NET.

Я хочу "предварительно прогреть"«эти вызовы для определенных« популярных »мест (например, Нью-Йорк, Калифорния) при запуске моего приложения или вскоре после него.

Я не хочу просто делать это в Global asax (Application_Start), потому что приложение будет слишком долго запускаться.(я планирую предварительно кэшировать около 15 местоположений, так что это несколько минут работы).

Есть ли способ, которым я могу запустить эту логику асинхронно?Может быть, сервис на стороне является лучшим вариантом?

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

Любой совет?

Answer 1

Просмотрите «Всегда работающий» параметр приложения для IIS 7.5. Что в основном делает, так это готовит пул приложений всякий раз, когда существующий должен быть переработан. Конечно, самое первое заняло бы 40-60 секунд, но потом все было бы быстро, если вы физически не перезагрузите машину.

Answer 2

Быстрым и грязным способом было бы отключить Task с Application_Start

Но я обнаружил, что приятно обернуть эту функцию в небольшую часть инфраструктуры, чтобы вы могли создаватьстраница ~ / Admin / CacheInfo, позволяющая отслеживать ход выполнения, состояние и исключения, которые могут находиться в процессе загрузки кэша.

Answer 3

Звучит так, будто вы должны просто вывести результаты в отдельную таблицу и назначить запланированное задание для периодического повторного заполнения этой таблицы.

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

Answer 4

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

Answer 5

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

Answer 6

Одним из решений является запуск рабочего потока в вашем Application_Start методе , который выполняет предварительный прогрев в фоновом режиме.Если вы все сделаете правильно, ваше приложение не займет больше времени для запуска, потому что поток будет выполняться асинхронно.

Answer 7

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

Answer 8

Загрузка в Task из Application_Start - это путь, о котором говорил Скотт.

Просто будьте осторожны - если ваш сайт перезапускается и 10 человек пытаются просмотреть Калифорнию, выне хочу, чтобы 10 экземпляров _repo.Get(x.ToKey()); // call db одновременно пытались загрузить одни и те же данные.

Возможно, было бы неплохо сохранить логическое значение "IsPreloading" в состоянии приложения.Установите значение true в начале функции предварительной загрузки и false в конце.Если значение установлено, убедитесь, что вы не загружаете ни одно из 15 предварительно загруженных местоположений в FindXForX.