Используйте статические или синглетные классы вместо системных.Сеть.Строки httpruntime.Тайник?

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

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

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

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

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

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

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

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

2 2
singleton http-caching asp.net-4.0

2 ответа:

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

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

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

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

0

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

                    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