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

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

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

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

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

Ответ 1

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

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

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

Ответ 2

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

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

Ответ 3

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

Ответ 4

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

Ответ 5

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

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