Преимущества Cache vs Session

В чем разница между хранением данных в Session vs Cache? Каковы преимущества и недостатки?

Итак, если это простая страница поиска, которая возвращает результат в datatable и привязывает его к gridview. Если пользователь ищет "поиск" и пользовательский "b", лучше ли его хранить в сеансе, поскольку каждый пользователь, скорее всего, имеет разные результаты или я могу сохранить каждый из своих поисков в кеше, или это не имеет смысла, поскольку существует только один кэш. Я предполагаю, что в основном то, что я пытаюсь сказать, это перезапись кэша.

Ответ 1

Важным отличием является то, что элементы в кеше могут истечь (будут удалены из кеша) через определенное количество времени. Элементы, помещенные в сеанс, будут оставаться там до окончания сеанса.

ASP.NET также может удалять элементы из кеша, когда количество доступной памяти становится небольшим.

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

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

Ответ 2

AFAIK. Ключевое различие заключается в том, что сеанс для каждого пользователя, а кеш - для объектов с областью приложения.

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

Это действительно зависит от того, чего вы пытаетесь достичь, сколько времени у вас есть. Есть несколько других альтернатив, которые следует учитывать в отношении того, как вы сохраняете состояние в приложении. В зависимости от того, насколько велика таблица, вы можете рассмотреть вопрос о сохранении состояния в файле cookie (зашифрованном, если это конфиденциальная информация). В качестве альтернативы, если в области данных с областью применения вы используете холодное использование статического поля на странице или классе. Также есть объект 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. Измерьте снова...

Ответ 3

Еще одно важное отличие: Состояние сеанса будет заблокировано, если выполняются одновременные асинхронные запросы Ajax, это приведет к результативности

Ответ 4

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

Ответ 5

Ну, это зависит от того, как вы настроили сеанс для ASP.NET. Вы сохраняете сеанс в базе данных или в памяти? Если в памяти используется отдельный сервер или вы используете текущий веб-сервер для сеанса?

В зависимости от того, как вы настроены для вас, могут возникнуть последствия для производительности, когда вы используете что-то вроде данных, которые говорят мне, что вы, возможно, храните большие объемы данных.

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

Ответ 6

Сессия для каждого пользователя, кэш предназначен для приложения.

Элементы в кэше могут и будут удаляться автоматически в зависимости от времени истечения срока действия (скользящего или фиксированного) и ограничений памяти рабочего процесса IIS.

Таким образом, в основном элементы в кеше никогда не будут существовать, но сеанс останется там до окончания сеанса.

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

Вдобавок ко всему, если IIS сбрасывает рабочий процесс, вы можете потерять кеш и сеанс.

Ответ 7

См. этот ответ.

Сессия может убить производительность вашего приложения, если вы не используете какой-либо бэкэнд-провайдер, такой как memcached или скорость. Обычно вам следует избегать этого.

Ответ 8

Насколько я знаю, все зависит от ваших потребностей.

Всякий раз, когда вам нужно поддерживать состояние для пользователей, вы должны быть очень осторожны при использовании сеансов. По умолчанию установлено значение "InProc", которое использует память отдельного сервера, плохо работает в облачных приложениях. Это может быть применимо к тем из вас, кто размещает ваше приложение в средах с несколькими экземплярами веб-фермы. Балансировщик нагрузки Windows Azure использует циклическое распределение внутри подключенных узлов.

У вас есть несколько вариантов в хранилище сеансов. SQL Server также можно использовать в качестве хранилища состояния сеанса. Пользовательские методы сеанса доступны в Azure, как поставщик хранилища таблиц и т.д.

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

На самом деле, разработчики не заботятся о влиянии методов управления состоянием при применении этого метода в приложениях. Это

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