Преимущества Cache vs Session
Вопрос
В чем разница между хранением данных в Session vs Cache? Каковы преимущества и недостатки?
Итак, если это простая страница поиска, которая возвращает результат в виде данных и связывает его с сеткой. Если пользователь «a» выполняет поиск и пользователь «b» выполняет поиск, лучше сохранить его в сеансе, поскольку каждый пользователь, скорее всего, будет иметь разные результаты, или я все еще могу сохранять каждый из своих поисков в кэше, или это не имеет смысла, так как существует только один кеш. Я предполагаю, что в основном я пытаюсь сказать, что кэш будет перезаписан.
Решение
Одним из важных отличий является то, что элементы в кеше могут истечь (будут удалены из кеша) через определенный промежуток времени. Элементы, помещенные в сеанс, будут оставаться там до тех пор, пока сеанс не закончится.
ASP.NET также может удалять элементы из кэша, когда объем доступной памяти становится небольшим.
Еще одно отличие: состояние сеанса может быть внешним (сервер состояний, сервер SQL) и совместно использоваться несколькими экземплярами вашего веб-приложения (для балансировки нагрузки). Это не относится к кешу.
Помимо этих отличий (как уже отмечали другие): сессия на пользователя / сессия, а кэш на приложение.
Другие советы
AFAIK, ключевое различие заключается в том, что сессия выполняется для каждого пользователя, а кеш - для элементов области приложения Р>
Как отмечалось в других ответах, вы можете хранить информацию о пользователях в кеше, предоставляя ключ (по сеансу или по cookie). Тогда у вас будет больше возможностей контролировать элементы в кэше, а также устанавливать зависимости от них. Таким образом, если рассматриваемый DataTable будет меняться на регулярной основе, то, вероятно, кеширование является подходящим вариантом. В противном случае, если это статический сеанс, может быть более подходящим. У Стивена Смита есть отличное видео о кэшировании на dnrtv , которое стоит посмотреть. Р>
Это действительно зависит от того, чего вы пытаетесь достичь, сколько у вас есть времени. Существуют и другие альтернативы, которые следует учитывать при хранении состояния в приложении. В зависимости от размера таблицы, вы можете рассмотреть возможность сохранения состояния в куки (зашифрованном, если это конфиденциальная информация). В качестве альтернативы, если это данные области приложения, вы можете использовать статическое поле на странице или в классе. Также есть объект Application. Р>
Обновление . Я думаю, что ключевой вопрос, который вы должны задать себе, - это кто должен видеть эти данные. Р>
Are they going to access the data frequently?
(Нет, не беспокойся). Р>
Is it going to change?
(Нет, используйте статическое поле или приложение). Р>
Is it acceptable for user a and user b to see the same results?
(Нет, используйте кеш с ключом, состоящим из имени пользователя и условия поиска.).
(Да, используйте кеш, используя ключ поискового запроса).
Честно говоря, если вы не далеко продвинулись в своем развитии, я бы рассмотрел вопрос о переносе кэширования / состояния на более поздний срок - он может даже не понадобиться. Р>
Первые три правила настройки производительности: 1. Измерьте, 2. Измерьте еще немного. 3. Снова измерить ...
Еще одно важное отличие: Состояние сеанса будет заблокировано , если будут выполняться параллельные асинхронные запросы Ajax, это повлияет на производительность
Кэш находится в области приложения с целью уменьшения количества получаемых фрагментов данных. Сессия находится в области действия пользователя с целью определения определенного пользовательского состояния.
Ну, это зависит от того, как у вас настроен сеанс для ASP.NET. Вы храните сеанс в базе данных или в памяти? Если в памяти вы используете отдельный сервер или используете текущий веб-сервер для сеанса?
В зависимости от того, как все настроено для вас, могут возникнуть проблемы с производительностью, когда вы используете что-то вроде таблицы данных, которая говорит мне, что вы, возможно, храните большие объемы данных.
Кроме того, сеанс сохраняется для каждого пользователя и извлекается для каждого пользователя посредством его билета сеанса, который хранится либо в файле cookie сеанса, либо в URL-адресе, если они не принимают файлы cookie, и вы настроили ASP.NET в режим без файлов cookie. Все, что вы кэшируете, будет кэшироваться на уровне приложения и будет доступно для всех пользовательских сессий, которые могут быть, а могут и не быть такими, какие вы хотите.
Сеанс для пользователя, кэш для приложения.
Элементы в кэше могут и будут удаляться автоматически в зависимости от времени истечения (скользящего или фиксированного) и ограничений памяти рабочего процесса IIS. Р>
Таким образом, в принципе, элементы в Cache никогда не гарантируются, но Session останется там до конца сеанса.
Хранение элементов для каждого пользователя (через сеанс или творческое использование Cache) может привести к значительному использованию памяти и должно быть тщательно продумано.
Помимо всего этого, если IIS сбрасывает рабочий процесс, вы можете потерять кэш и сеанс.
См. этот ответ . Р>
Сеанс может снизить производительность вашего приложения, если вы не используете какой-либо бэкэнд-провайдер, такой как memcached или speed. Как правило, вы должны избегать этого.