Можно ли использовать статические переменные для кэширования информации в ASP.net?

Question

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

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

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

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

Answer 1

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

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

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

Answer 2

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

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

Answer 3

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

Answer 4

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

Answer 5

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

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