Использовать статические или одноэлементные классы вместо System.Web.HttpRuntime.Cache? - PullRequest
Новая
       22

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

2 голосов
/ 21 марта 2012

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

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

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

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

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

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

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

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

Ответы [ 2 ]

0 голосов
/ 23 марта 2012

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

                    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);

... Я еще не подтвердил это.

0 голосов
/ 23 марта 2012

Сколько будет стоить изменение кода по сравнению с покупкой большего количества памяти?

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

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

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

...