Вопрос

В чем разница между хранением данных в 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. Как правило, вы должны избегать этого.

Лицензировано под: CC-BY-SA с атрибуция
Не связан с StackOverflow
scroll top