Кэширование в ASP.NET - PullRequest
       17

Кэширование в ASP.NET

2 голосов
/ 28 ноября 2008

Я хочу кешировать пользовательские данные в приложении ASP.NET. Я помещаю в него много данных, таких как List и другие объекты.

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

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

Обновление 1:

Только что нашел это, что, вероятно, помогает мне

http://www.codeproject.com/KB/web-cache/cachemanagementinaspnet.aspx?fid=229034&df=90&mpp=25&noise=3&sort=Position&view=Quick&select=2818135#xx2818135xx

Обновление 2:

Я использую DotNetNuke в качестве приложения, (:(). Я включил постоянное кэширование, и теперь все приложение чувствует себя вялым.

Например, для Multiview требуется около 3 секунд для смены вида ....

Обновление 3:

Стратегии кэширования в Интернете?

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

У меня есть помощник:

CachingProvider.Instance().Add( _
    (label & "|") + key, _
    newObject, _
    Nothing, _
    Cache.NoAbsoluteExpiration, _
    Cache.NoSlidingExpiration, _
    CacheItemPriority.NotRemovable, _
    Nothing)

Что запускается для добавления объектов в кеш, это правильно? Так как я хочу сохранить его в кеше как можно дольше. У меня есть поток, который запускается каждые х минут, который будет обновлять кэш. Но я заметил, что кеш очищается, я проверяю объект "CacheFilled" в кеше.

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

Ответы [ 4 ]

2 голосов
/ 01 декабря 2008

Вы ищете либо внеплановое кэширование, либо какую-то распределенную систему кэширования, основанную на ваших требованиях. Я рекомендую распределенное кэширование, потому что оно очень масштабируемо и предназначено для кэширования. Кто-то еще порекомендовал Velocity, который мы оценивали и полностью наслаждались. Мы написали несколько провайдеров кэширования, которые мы можем обмениваться, пока мы оцениваем различные системы распределенного кэширования без необходимости перестраивать. Это пригодится, когда мы будем тестировать различные системы под нагрузкой в ​​рамках окончательной оценки.

В прошлом наше устаревшее приложение представляло собой случайный ассортимент кэшированных элементов. Были DataTables, DataViews, Hashtables, Arrays и т. Д., И не было никакой логики для того, что использовалось в любой момент времени. Мы начали переходить к простому кэшированию коллекций наших доменных объектов (которые являются POCO). Использование общих коллекций - это хорошо, потому что мы знаем, что все хранится одинаково. Выполнять над ними операции LINQ очень просто, и если нам нужно сохранить специализированное «представление», система достаточно эффективна для того, чтобы мы могли хранить определенную коллекцию объектов.

Мы также создали слой абстракции, который в значительной степени вызывается посредниками между DAL или моделью кэширования. Звонки через этот слой будут проверять наличие кеша или попадания в кеш. Если будет хит, он вернется из кеша. Если происходит промах, и вызов должен быть кэширован, он попытается кэшировать данные после их получения. Непосредственным преимуществом этой системы является то, что в случае аппаратного или программного сбоя на машинах, предназначенных для кэширования, мы по-прежнему можем извлекать данные из базы данных без истинного сбоя. Конечно, в этом случае сайт будет работать медленнее.

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

2 голосов
/ 28 ноября 2008

Также обратите внимание на блок MS Enterprise Caching Application, который позволяет вам написать собственную политику истечения срока действия, пользовательское хранилище и т. Д. http://msdn.microsoft.com/en-us/library/cc309502.aspx

Вы также можете проверить «Скорость», которая доступна на http://code.msdn.microsoft.com/velocity

Это будет полезно, если вы хотите масштабировать ваше приложение по серверам ...

1 голос
/ 01 декабря 2008

Кэш и сеанс могут привести к вялому поведению, но иногда они являются правильными решениями: применяется правило правильного инструмента для правильной работы.

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

По сути, я рекомендую его как опору производительности, но не полагайтесь на него, если требуется настоящее упорство.

1 голос
/ 28 ноября 2008

Существует множество статей об объекте Cache в ASP.NET и о том, как заставить его использовать SqlDependencies и другие типы срока действия кэша. Не нужно писать свои собственные. И использование кэша рекомендуется во время сеанса или любой другой коллекции, в которую люди втиснули множество данных.

Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...