Используйте статические или одноэлементные классы вместо System.Web.HttpRuntime.Cache?

Question

Я твердо убежден, что бросать аппаратное обеспечение для решения проблем с программным обеспечением - это не лучшая политика. Поэтому, заметив несколько проблем с памятью с одним из наших серверов (в настоящее время работающим с двумя гигабайтами), я отследил его до использования System.Web.HttpRuntime.Cache. Хотя для нескольких сайтов это имело смысл, выбросив 50 сайтов, которые все используют System.Web.HttpRuntime.Cache, начали сбивать стены.

Без опции внешнего сервера кеширования с учетом для изменения кода, использующего статические классы или синглтоны для глобального хранения данных (другой вариант - делать дополнительные запросы db).

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

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

- Обновление -

В мониторинг использования кэш-памяти Текущий файл, я заметил это число шип, как я ударил несколько сайтов на одном пуле приложений. Это число подскочило до немногих 1 000 000 (байты, которые я предполагаю). Я замечаю, что это число в конце концов начинает уменьшаться, так как число Активных промытых записей увеличивается, а затем уменьшается.

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

Вместо того, чтобы просто вырывать кеширование (что, как было предложено, возможно, не самая лучшая идея), простое установление более быстрого срока истечения для кешированных объектов может привести к лучшим результатам?

Answer 1

Что это будет стоить, чтобы изменить код и купить больше памяти?

Я бы сказал, что веб-сервер Windows с 2 ГБ ОЗУ не указан.

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

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

Answer 2

Просматривая код на этих сайтах, я нашел следующее:

    HttpRuntime.Cache.Insert(
         /* key */    "WebsiteConfiguration", 
         /* value */    website, 
         /* dependencies */  null, 
         /* absoluteExpiration */ Cache.NoAbsoluteExpiration, 
         /* slidingExpiration */ Cache.NoSlidingExpiration, 
         /* priority */   CacheItemPriority.NotRemovable, 
         /* onRemoveCallback */ null); 

Я думаю, что главная проблема может быть с NoSlidingExpiration и NotRemovable.

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

if (System.Web.HttpRuntime.Cache["WebsiteConfiguration"] == null) 
. 
. 
. 

        HttpRuntime.Cache.Insert(
         /* key */    "WebsiteConfiguration", 
         /* value */    website, 
         /* dependencies */  null, 
         /* absoluteExpiration */ Cache.NoAbsoluteExpiration, 
         /* slidingExpiration */ new TimeSpan(0,0,30),    // zero timespan or not long enough will cause a null ref exception when used 
         /* priority */   CacheItemPriority.Normal, 
         /* onRemoveCallback */ null);  

... Я до сих пор, чтобы подтвердить это.