Преимущества кеша перед сеансом
В чем разница между хранением данных в Session vs Cache? Какие преимущества и недостатки?
Итак, если это простая страница поиска, которая возвращает результат в виде таблицы данных и связывает ее с представлением сетки. Если пользователь «a» выполняет поиск, а пользователь «b» выполняет поиск, лучше ли сохранить его в сеансе, поскольку каждый пользователь, скорее всего, будет иметь разные результаты, или я все еще могу хранить каждый из их поисков в кеше, или это не имеет смысла, поскольку есть только один кеш. Я предполагаю, что в основном я пытаюсь сказать, что кеш будет перезаписан.
HttpContext.Current.Cache vs HttpRuntime.Cache?
@Kiquenet Я действительно восхищался твоими усилиями.
@Kiquenet Тогда позвольте мне сказать вам, что я понимаю по этому поводу. HttpContext относится к текущему запросу. Он жив только в течение времени жизни запроса. Но HttpRuntime все время остается в живых. Таким образом, ваш кеш жив до тех пор, пока срок его действия не истечет. Я не уверен, но это то, что я увидел, когда тестировал его.
Ответы 8
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. Измерьте еще раз ...
только если вы сделаете ключ кеша для этого идентификатора сеанса
Вы говорите Измеряйте больше, больше, снова. Как измерения лучше, шаблоны и практики? любой образец?
Кэш находится в области действия приложения с целью уменьшения количества получений фрагментов данных. Сеанс находится в области сеанса пользователя с целью предоставления определенного состояния пользователя.
Ну, это зависит от того, как вы настроили сеанс для ASP.NET. Вы храните сеанс в базе данных или в памяти? Если в памяти используется отдельный сервер или текущий веб-сервер для сеанса?
В зависимости от того, как все настроено для вас, могут возникнуть проблемы с производительностью, когда вы используете что-то вроде таблицы данных, которая говорит мне, что вы, возможно, храните большие объемы данных.
Также сеанс хранится для каждого пользователя и извлекается для каждого пользователя с помощью их билета сеанса, который хранится либо в файле cookie сеанса, либо в URL-адресе, если они не принимают файлы cookie и вы настроили ASP.NET в режим без файлов cookie. Все, что вы кешируете, будет кэшироваться на уровне приложения и будет доступно для всех пользовательских сеансов, которые могут быть или не быть тем, что вы хотите.
Сеанс для каждого пользователя, кеш для приложения.
Элементы в кэше могут и будут удаляться автоматически в зависимости от времени истечения срока (скользящего или фиксированного) и ограничений памяти рабочего процесса IIS.
Таким образом, в основном элементы в кэше никогда не гарантированно существуют, но сеанс останется там до завершения сеанса.
Хранение элементов для каждого пользователя (через сеанс или творческое использование кеша) может привести к большому использованию памяти, и к нему следует относиться внимательно.
Вдобавок ко всему, если IIS сбрасывает рабочий процесс, вы можете потерять кэш и сеанс.
сессия тоже не гарантируется.
Одно из важных отличий заключается в том, что элементы в кеше могут истечь (будут удалены из кеша) по прошествии определенного времени. Элементы, помещенные в сеанс, останутся там до завершения сеанса.
ASP.NET также может удалять элементы из кеша, когда объем доступной памяти становится небольшим.
Еще одно отличие: состояние сеанса может быть внешним (сервер состояний, SQL-сервер) и совместно использоваться несколькими экземплярами вашего веб-приложения (для балансировки нагрузки). С кешем дело обстоит иначе.
Помимо этих различий (как отмечали другие): сеанс предназначен для каждого пользователя / сеанса, а кеш - для каждого приложения.
На самом деле кеш можно хранить извне с помощью Velocity
Может быть реализован кеш, который хранит значения извне, но платформа .Net по умолчанию не поддерживает внешний кеш. Однако для сеансов поддерживаются внешние сеансы.
Еще одно предостережение: IIS будет гидратировать весь сеанс, каждый запрос по сравнению с кешем может быть более детальным.
проверьте другие параметры! Какой из них самый безопасный? Какие из них имеют наибольший размер? какой из них безошибочный?
См. этот ответ.
Сессия может снизить производительность вашего приложения, если вы не используете какой-либо серверный провайдер, такой как memcached или скорость. Как правило, вам следует избегать этого.
Еще одно важное отличие: Состояние сеанса будет заблокировано, если выполняются параллельные асинхронные запросы Ajax, это повлияет на производительность.
Насколько я знаю, все зависит от ваших потребностей.
Всякий раз, когда вам нужно поддерживать состояние для пользователей, вы должны быть очень осторожны при использовании сеансов. Настройка по умолчанию - «InProc», которая использует память отдельного сервера, плохо работает в облачных приложениях. Это может быть применимо для тех из вас, кто размещает свое приложение в среде веб-фермы с несколькими экземплярами. Балансировщик нагрузки Windows Azure использует циклическое распределение внутри подключенных узлов.
У вас есть несколько вариантов в хранилище сеансов. SQL Server также можно использовать в качестве хранилища состояния сеанса. Пользовательские методы сеанса доступны в Azure, например, поставщик хранилища таблиц и т. д.
Кэш также хранится в памяти сервера, но это не имеет отношения к пользователям. Любой пользователь в том же пуле может получить доступ к данным кеша приложения. Короче говоря, в облаке нам нужно использовать службу кэширования, предоставляемую поставщиками облачных услуг. Azure предоставляет службу распределенного кэширования Windows Azure.
На самом деле разработчики не заботятся о влиянии методов управления состоянием при их применении в приложениях. Это
«Если у вашего клиента нет облачной поддержки, то вам не стоит беспокоиться об облачных сценариях»
Вы должны кэшировать данные, которые вы хотите, чтобы все пользователи использовали в приложении. Данные, которые могут не измениться исторически. Сессия должна использоваться для хранения данных для пользовательского контекста, например, если это похоже на результаты фильтрации кэшированных данных.