50GB HttpRuntime.Cache персистентность возможно? - PullRequest
Новая
       23

50GB HttpRuntime.Cache персистентность возможно?

2 голосов
/ 17 сентября 2011

У нас есть приложение ASP.NET 4.0, которое извлекает из базы данных сложную структуру данных, которая занимает более 12 часов, чтобы вставить в структуру данных в памяти (которая позже сохраняется в HttpRuntime.Cache). Размер структуры данных быстро увеличивается, и мы не можем продолжать ждать более 12 часов, чтобы поместить его в память, если приложение перезапустится. Это серьезная проблема, если вы хотите изменить файл web.config или любой другой код в веб-приложении, вызывающий перезапуск. Это означает длительное ожидание использования приложения и затрудняет разработку или обновление развертывания.

Структура данных ДОЛЖНА быть в памяти, чтобы работать со скоростью, которая делает веб-сайт пригодным для использования. В базах данных памяти, таких как memcache или Redis, медленнее по сравнению с HttpRuntime.Cache и не будет работать в нашей ситуации (в БД памяти нужно сериализовать put / get, плюс они не могут ссылаться друг на друга, они используют ключи, которые являются поисками - снижение производительности, плюс при большом количестве клавиш производительность быстро снижается). Производительность является обязательным здесь.

То, что мы хотели бы сделать, - это быстро сбросить HttpRuntime.Cache на диск до того, как приложение завершится (при перезапуске), и иметь возможность загрузить его обратно сразу же после запуска приложения (надеюсь, в течение нескольких минут вместо 12+ часов). или дни).

Структура оперативной памяти составляет около 50 ГБ.

Есть ли решение для этого?

1 Ответ

8 голосов
/ 17 сентября 2011

В базах данных памяти, таких как memcache или Redis, медленные по сравнению с HttpRuntime.Cache

Да, но они очень быстрые по сравнению с ускорением 12+ часов.Лично я думаю, что вы используете неправильный подход для принудительной загрузки структуры размером 50 ГБ.Просто предложение, но мы используем HttpRuntime.Cache как часть многоуровневой стратегии кэширования:

  • проверяется локальный кеш и т. Д. Сначала
  • в противном случае redis используется в качестве следующего уровнякеш (который работает быстрее, чем базовые данные, постоянен и поддерживает несколько серверов приложений) (затем обновляется локальный кеш)
  • в противном случае выполняется обращение к базовой базе данных (а затем обновляются и Redis, и локальный кеш))

Дело в том, что при загрузке нам не требуется ничего в памяти - оно заполняется по мере необходимости, и с этого момента оно быстро.Мы также используем pub / sub (опять же любезно предоставленный redis), чтобы гарантировать быстрое аннулирование кэша.Итоговый результат: он быстрый достаточно в холодное время и очень быстрый в теплое время.

В принципе, я бы посмотрел на все, что избегает данных 50 ГБ перед вамиможет сделать что угодно .

Если эти данные на самом деле не кеш , а ваши данные , я бы посмотрел сериализациюна правильной объектной модели.Я бы предложил в качестве сильного кандидата protobuf-net (я предвзятый автор) - очень быстрый и очень маленький вывод.

...