Преимущества кэша против сеанса
в чем разница между хранением datatable в сеансе vs Cache? Каковы преимущества и недостатки?
Итак, если это простая страница поиска, которая возвращает результат в datatable и привязывает его к gridview. Если пользователь " a "ищет и пользователь" b " ищет, лучше ли хранить его в сеансе, так как каждый пользователь, скорее всего, будет иметь разные результаты или я все еще могу хранить каждый из своих поисков в кэше или это не имеет смысла, так как есть только один кэш. Я думаю, в основном я пытаюсь сказать, что кэш будет перезаписан.
8 ответов
одним из важных отличий является то, что элементы в кэше могут истечь (будут удалены из кэша) через определенное количество времени. Элементы, помещенные в сеанс, останутся там, пока сеанс не закончится.
ASP.NET можно также удалить элементы из кэша, когда объем доступной памяти становится небольшим.
другое отличие: состояние сеанса может быть внешним (сервер состояний, SQL server) и общим для нескольких экземпляров вашего веб-приложения (для балансировки нагрузки). Это не дело с тайником.
кроме этих различий (как отмечали другие): сеанс на пользователя/сеанс, а кэш-на приложение.
AFAIK, ключевым отличием является сеанс для каждого пользователя, в то время как кэш будет для элементов области приложения.
как отмечено в других ответах, вы можете хранить информацию о пользователе в кэше, предоставляя ключ (либо по сеансу, либо по cookie). Тогда у вас будет больше контроля для истечения срока действия элементов в кэше, а также установить зависимости от них. Поэтому, если рассматриваемый DataTable будет меняться на регулярной основе, кэширование, вероятно, является подходящим вариантом. В противном случае, если он статичен сеанс может быть более подходящим. Стивен Смит имеет отличное видео по кэшированию на dnrtv это стоит проверить.
Это действительно зависит от того, чего вы пытаетесь достичь, сколько времени у вас есть. Есть несколько других альтернатив, которые следует рассмотреть в отношении того, как вы храните состояние в приложении. В зависимости от размера таблицы вы можете сохранить состояние в файле cookie (зашифрованном, если это конфиденциальная информация). Альтернативно, если это приложение данные области вы используете статическое поле на странице или классе. Существует объект приложения, а также.
обновление: Я думаю, что ключевой вопрос вы должны спросить себя, кто должен видеть эти данные.
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 - ... Вы храните сеанс в базе данных или в памяти? Если в памяти вы используете отдельный сервер или используете текущий веб-сервер для сеанса?
в зависимости от того, как все настроено для вас, могут быть последствия для производительности, когда вы используете что-то вроде datatable, который говорит мне, что вы, возможно, храните большие объемы данных.
также сеанс сохраняется для каждого пользователя и извлекается для каждого пользователя с помощью их билета сеанса, который хранится либо в файле cookie сеанса, либо в URL-адресе, если они не принимают файлы cookie и вы настроили ASP.NET к cookieless режиму. Все, что вы кэшируете, будет кэшироваться на уровне приложения и будет доступно для всех пользовательских сеансов, которые могут быть или не быть тем, что вы хотите.
сеанс для каждого пользователя, кэш для приложения.
элементы в кэше могут и будут удалены автоматически в зависимости от времени истечения срока действия (скользящего или фиксированного) и ограничений памяти рабочего процесса IIS.
таким образом, в основном элементы в кэше никогда не гарантируются, но сеанс останется там до конца сеанса.
хранение элементов на основе каждого пользователя (через сеанс или творческое использование кэша) может привести к большому использованию памяти и должно быть внимательно рассмотреть.
кроме того, если IIS сбрасывает рабочий процесс, вы можете потерять кэш и сеанс.
посмотреть ответ.
сеанс может убить производительность вашего приложения, если вы не используете какой-то бэкэнд-провайдер, такой как memcached или velocity. Как правило, вы должны избегать его.