Кеширование пользовательских данных в приложении asp.net - PullRequest
2 голосов
/ 31 марта 2011

Каков наилучший способ кэширования пользовательских данных сайта в asp.net 4.0?

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

  1. Храните их в HttpContext.Current.Session напрямую (например, Session["setting_name"])
  2. Храните их в HttpContext.Current.Cache
  3. Использовать глобальный статический словарь, например, static ConcurrentDictionary<string,string> где ключ - это уникальный идентификатор пользователя + значение имени настройки
  4. Сохранение объекта словаря для каждого сеанса в Session или Cache

Какой самый разумный способ сделать это? Чем Session отличается от Cache с практической точки зрения? Имеет ли смысл когда-нибудь хранить словарь как отдельный объект сеанса / кэша, а не просто добавлять множество значений напрямую? Я думаю, что поиск может быть быстрее, но обновления будут медленнее, так как мне придется заново сохранять весь словарь, когда он изменился.

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

Ответы [ 2 ]

1 голос
/ 31 марта 2011

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

Кроме того, когда вы используете Session не в процессе, он в итоге получает сериализованный для отправки вне процесса или в базу данных, и десериализуется при получении, и вы эффективно делаете то, что вы описали выше:

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

.., поскольку, даже если вы используете отдельные ключи сеанса, весь объект Session для пользователя сериализуется идесериализованы вместе (все сразу).

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

Тем не менее, я бы посоветовал вам использовать Cache, если вы 'кеширование по соображениям производительности.

ps Да, вы слишком стараетесь.Не изобретайте велосипед, если вам действительно не нужно.: -)

0 голосов
/ 31 марта 2011

может быть лучше поместить вашу информацию в memcached для масштабируемости

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