Каков наиболее эффективный способ хранения / извлечения элементов в asp.net httpContext.Cache - PullRequest
17 голосов
/ 03 апреля 2012

У меня есть сайт, где я кеширую много информации.Я вижу противоречивую информацию о хранении вещей в кэше asp.net.

Например, допустим, у меня есть такая структура данных:

 Dictionary<string, List<Car>> mydictionary;

Я мог бы хранить все это с помощью строкового ключакак «MyDictionary», а затем развернуть, как только я вытащу объект.

 HttpContext.Cache.Add("MyDictionary",  
   mydictionary, 
   null, 
   Cache.NoAbsoluteExpiration,
   new TimeSpan(10, 0, 0),
   CacheItemPriority.Normal,
   null);

 var myDict = HttpContext.Cache["MyDictionary"] as Dictionary<string, List<Car>>;

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

 Dictionary<string, List<Car>> mydictionary;

 foreach (var item in mydictionary.Keys)
 {
      HttpContext.Cache.Add(item, mydictionary[item], null, Cache.NoAbsoluteExpiration, new TimeSpan(10, 0, 0), CacheItemPriority.Normal, null);
 }

 var myitem = "test";
 var myDict = HttpContext.Cache[myItem] as List<Car>;

Будет ли влияние на производительность сильно отличаться (учитывая, что я предполагаю, что все находится в памяти в любом случае?)

Ответы [ 3 ]

14 голосов
/ 09 апреля 2012

Добавление дополнительного ответа здесь, поскольку я чувствую, что существующий захватывает «что», но недостаточно «почему».

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

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

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

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

7 голосов
/ 09 апреля 2012

Как вы говорите, на этот счет есть два противоположных мнения.

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

Если вы используете только один элемент из словаря и не ходите пословарь, а затем хранить их на индивидуальном уровне.

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

3 голосов
/ 09 апреля 2012

Безусловно, второй способ лучше.

Подумайте о необходимости учитывать множество объектов.Каждый раз, когда вам нужно получить 1 значение, вам нужно только получить его, вместо того, чтобы собирать словарь энтайра и, следовательно, получать то, что вы хотите.

Это, не говоря об алгоритмах, используемых в кешерасставить приоритеты для наиболее часто используемых элементов (MRU, если я все еще помню).

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

...