Можно ли использовать статические переменные для кэширования информации в ASP.net? - PullRequest
23 голосов
/ 30 сентября 2008

В данный момент я работаю над приложением администратора проекта в C # 3.5 на ASP.net. Чтобы уменьшить количество попаданий в базу данных, я кеширую много информации, используя статические переменные. Например, список пользователей хранится в памяти в статическом классе. Класс считывает всю информацию из базы данных при запуске и обновляет базу данных при каждом внесении изменений, но ему никогда не нужно считывать данные из базы данных.

Класс пингует другие веб-серверы (если они существуют) с обновленной информацией одновременно с записью в базу данных. Механизм проверки связи - это служба Windows, в которой объект кэша регистрируется с использованием произвольно доступного порта. Используется и для других вещей.

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

Мне было интересно, есть ли какие-либо подводные камни в этом методе и / или есть ли лучшие способы для кэширования данных?

Ответы [ 5 ]

16 голосов
/ 30 сентября 2008

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

Лучше использовать объект Cache - он предназначен для таких вещей.

Редактировать: Оказывается, я ошибался насчет доменов приложений (как указано в комментариях) - больше экземпляров приложения будут создаваться под нагрузкой, но все они будут работать в одном и том же домене приложений. (Но вы все равно должны использовать объект Cache!)

4 голосов
/ 30 сентября 2008

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

4 голосов
/ 30 сентября 2008

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

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

0 голосов
/ 30 сентября 2008

Я предлагаю вам изучить способы создания распределенного кэша для вашего приложения. Вы можете взглянуть на NCache или indeXus.Net

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

0 голосов
/ 30 сентября 2008

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

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