Asp кэширование данных


Содержание

Кэширование данных в ASP.Net

Мне нужно заполнить несколько выпадающих ящиков из некоторых справочных данных. Список городов, Список стран и т.д. Мне нужно заполнить его в различных веб-формах. Я думаю, мы должны кэшировать эти данные в нашем приложении, чтобы мы не попадали в базу данных по каждой форме. Я новичок в кэшировании и ASP.Net. Пожалуйста, предложите мне, как это сделать.

Я всегда добавляю следующий класс ко всем моим проектам, которые дают мне легкий доступ к объекту Cache. Реализация этого, после ответа Хасана Хана, будет хорошим способом.

Из вашего другого вопроса я прочитал, что вы используете трехслойную архитектуру с dal, бизнес-и презентационным уровнем.

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

Например: если у вас есть интерфейс IUserRepository, тогда класс UserRepository будет реализовывать его и добавлять/удалять/обновлять записи в db с помощью методов, тогда вы также можете иметь CachedUserRepository, который будет содержать экземпляр объекта UserRepository, а в методах get он сначала будет изучать кеш против некоторого ключа (полученный из параметров метода), и если элемент найден, он возвращает его, иначе вы вызываете метод на внутреннем объекте; получить данные; добавьте в кеш и верните его.

Блог о технологиях .NET

16 мая 2011 г.

Кэширование в ASP.NET Часть 1. Введение

  1. Класс Cache – архитектура и свойства;
  2. Работа с объектом Cache;
  3. Настройка зависимостей в объекте Cache;
  4. Зависимости от данных XML;
  5. Зависимости от базы данных SQL Server.

Get – возвращает запись из кэша, хранящуюся с указанным ключом. Если такая запись не найдена метод возвращает null;

GetEnumerator – возвращает объект-перечислитель, позволяющий перемещаться по всем элементам коллекции;

Использование кэширования в Web-приложениях

Цель лекции: изучить принципы использования кэширования при создании Web-приложений. На практических примерах рассмотреть возможности ASP . NET по организации различных видов кэширования как целых страниц, так и их частей.

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

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

Но применение кэширования не только приводит к повышению производительности и масштабируемости, но и создает ряд проблем, которые необходимо знать и уметь их обходить. Одна из таких проблем — это то, что кэширование задействует оперативную память , которая никогда не бывает лишней. Если попытаться сохранить в оперативной памяти слишком много данных, операционная система сбрасывает лишние данные на диск , что может привести к замедлению работы всей системы в целом. Для управления этим процессом в ASP . NET реализован интеллектуальный механизм определения переполнения кэша, который основан на том, что при попытке записи в кэш данных, объем которых превышает доступный для кэша объем оперативной памяти, ASP . NET выборочно удалит из кэша часть данных для обеспечения максимальной общей производительности системы. Кроме того, при использовании механизмов кэширования необходимо помнить, что должен быть некий принцип, согласно которому будет осуществляться проверка обновления информации в кэше. Если данные таблицы базы данных или файла изменились, это может означать, что данные кэша устарели и их необходимо обновить. ASP . NET 2.0 предоставляет усовершенствованный механизм управления кэшированием , реализуя все необходимые элементы управления политикой кэширования. В частности, он позволяет управлять замещением информации, находящейся в кэше, управлять профилями кэшей, с помощью которых можно определить настройки кэширования для группы страниц, управлять хранением содержимого кэша в оперативной памяти и на жестких дисках, отслеживать изменения в исходных данных и удалять или объявлять недействительными кэшированные элементы.

Основы кэширования в ASP.NET

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

Кэширование данных управляется непосредственно из кода ASPNET-приложения, в котором разработчик сам определяет, какую информацию необходимо поместить в кэш . Страницы, к которым обращаются пользователи, могут проверять существование интересующей их информации в кэше, прежде чем выполнять шаги, необходимые для ее получения. В этом смысле кэширование можно сравнить с состоянием приложения, с той лишь разницей, что при невозможности сохранения данных в кэше они удаляются; кроме того, возможно настроить автоматическое удаление данных из кэша по истечении определенного времени.

Кэширование вывода позволяет сохранить копию сгенерированной HTML-страницы, отправленной клиенту. Таким образом, если еще один или несколько клиентов запросят у сервера ту же страницу, они получат ее копию из кэша.


Упомянутые виды кэширования стали основой для создания еще двух разновидностей.

  • Кэширование фрагментов — позволяет сохранять в кэше лишь часть готового HTML-кода страницы. В основном это относится к пользовательским элементам управления.
  • Кэширование источников данных — встроенный в объекты доступа к данным механизм кэширования данных, который запускается автоматически при использовании соответствующего элемента.

Рассмотрим основные аспекты применения кэширования в ASP . NET

Кэширование вывода

При использовании данного вида кэширования сгенерированный в результате выполнения приложения HTML-код сохраняется в памяти, и при повторном запросе этой же страницы клиенту передается уже сгенерированный ранее HTML-код.

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

Создадим новое Web- приложение , откроем редактор кода страницы и введем следующую команду в обработчик события Page_Load :

При запуске на страницу будет выводиться текущая дата и время. Если нажать кнопку «Обновить» в окне браузера, показания времени изменятся в соответствии с текущим значением системных часов.

Добавим данную страницу в кэш . Для этого добавим к файлу страницы директиву

Атрибут Duration задает количество секунд, в течение которых необходимо хранить страницу в кэше. Параметр VaryByParam , равный значению None , устанавливает режим кэширования, при котором, независимо от дополнительных параметров, в кэше будет сохраняться только одна копия данной страницы.

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

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

Выше уже отмечались некоторые потенциальные проблемы, связанные с кэшированием страницы вывода. Одним из таких случаев является использование данных, передаваемых странице через строку запроса. При установленном режиме кэширования, рассматриваемом выше, несмотря на ввод в строку адреса значений переменных страница сохраняется в кэше заданные 10 секунд. Однако такое поведение можно изменить, если указать в качестве значения параметра VaryByParam значение «*», которое устанавливает режим кэширования страниц, содержащих строку запроса. При этом ASP . NET начинает кэшировать отдельные копии страницы для разных значений аргументов, указанных в строке запроса.

Использование значения «*» в качестве значения параметра VaryByParam в некоторых случаях способно вызвать дополнительные проблемы. Дело в том, что в некоторых типах приложений достаточно часто применяется передача множества параметров в строке запроса. Если значение хотя бы одного из передаваемых параметров будет отличаться от значения такого же параметра кэшированной страницы, запрашиваемая страница будет кэширована вновь. Например, если в строке запроса передается информация о клиенте, а также о выбранном им товаре, понятно, что количество комбинаций клиента и товара достаточно велико, а следовательно, практически все запрашиваемые страницы будут помещены в кэш , причем их повторное использование будет стремиться к 0. В этом случае целесообразно выявить те параметры, которые наиболее часто нужны для передачи параметров с высокой степенью повторного использования, и указать их в качестве значения параметра VaryByParam . Например, следующая строка дает команду ASP . NET для кэширования только тех страниц, которые содержат параметр ClientID , чье значение , в свою очередь , отличается от уже сохраненного в кэше.

IT-ЗАМЕТКИ

Инструменты пользователя

Инструменты сайта

Содержание

На основе этих моделей построены также два специализированных типа кэширования.

Кэширование вывода

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

Илон Маск рекомендует:  Как увеличить расстояние от маркера до текста

Декларативное кэширование вывода

Существуют два способа добавить страницу в кэш вывода. Наиболее распространенный подход заключается во вставке директивы OutputCache в начало файла .aspx, непосредственно под директивой Page:

В этом примере атрибут Duration инструктирует ASP .NET о том, что страницу нужно хранить в кэше в течение 20 секунд.

В рассматриваемом примере атрибут VaryByParam устанавливается в None. Это сообщает ASP .NET, что мы хотим хранить только одну копию кэшируемой страницы, которая подходит для всех сценариев.


Кэширование и строка запроса

Значение атрибута VaryByParam можно установить в «*», указав, что страница использует строку запроса, и таким образом проинструктировать ASP .NET о том, что нужно кэшировать отдельные копии страницы для разных значений аргументов в строке запроса:

Кэширование со специфичными параметрами строки запроса

Установка VaryByParam=«*» позволяет использовать кэширование с динамическими страницами, которые варьируют свой вывод в зависимости от строки запроса. Этот подход может быть исключительно полезен для детальной страницы товара, которая принимает идентификатор товара в строке запроса. При кэшировании с варьированием параметров можно сохранять отдельную страницу для каждого товара, таким образом, экономя на обращениях к базе данных. Однако чтобы получить выигрыш в производительности, может понадобиться увеличить время существования кэшированного вывода до нескольких минут или больше.

Во многих ситуациях установка VaryByParam=«*» вносит ненужную неопределенность. Обычно лучше специально идентифицировать важную переменную строки запроса по имени. Вот пример:

В этом случае будут кэшироваться отдельные версии выходной страницы, если строка запроса отличается по ProductID или CurrencyType.

Кэширование с помощью класса HttpCachePolicy

Однако есть и другой выбор: можно написать код, использующий специальное встроенное свойство Response.Cache, которое предоставляет экземпляр класса System.Web. HttpCachePolicy. Этот объект содержшнсвойства, позволяющие включать кэширование для текущей страницы. Это позволяет программно решить, нужно ли включать кэширование вывода.

Послекэшевая подстановка

Средство послекэшевой подстановки вращается вокруг единственного метода, добавленного в класс HttpResponse. Этот метод называется WriteSubstitution() и принимает один параметр — делегат, указывающий на метод обратного вызова, который вы реализуете в своем классе страницы. Метод обратного вызова возвращает содержимое этой части страницы.

Теперь, даже если применить кэширование к этой странице с помощью директивы OutputCache, вторая дата, отображаемая на странице, все равно будет обновляться при каждом запросе, потому что обратный вызов минует процесс кэширования.

Конфигурация кэша

Для конфигурирования этих настроек используется элемент внутри описанного ранее элемента . Элемент предоставляет несколько опций для настройки:

Используйте disableMemoryCollection и disableExpiration для прекращения сбора элементов ASP .NET, когда объем свободной памяти ограничен (процесс называется очисткой), и удаления устаревших элементов.

Кэширование юзер контрола

Кэширование данных

Кэширование данных — наиболее гибкий тип кэширования, однако для своей реализации он требует выполнения в коде ряда дополнительных шагов. Базовый принцип кэширования данных состоит в добавлении элементов, создание которых обходится дорого, в специальный встроенный объект коллекции (называемый Cache). Этот объект работает во многом подобно объекту Application. Он доступен глобально всем запросам от всех клиентов в приложении. Однако существуют несколько ключевых отличий.

Как и состояние приложения, кэшируемый объект привязан к процессу. Это означает, что он не должен существовать после перезапуска домена приложения, и не может быть разделен между компьютерами в веб-серверном кластере. Такое поведение заложено при проектировании, потому что цена, которую пришлось бы заплатить за предоставление возможности многим компьютерам взаимодействовать с внепроцессным кэшем, свела бы на нет выигрыш в производительности. Поэтому больше смысла позволить каждому веб-серверу иметь собственный кэш.

Добавление элементов в кэш

Более предпочтительный подход добавления кеша в память это применении метода Insert():

Перегрузка Описание
Cache.Insert(key,value) Вставляет элемент в кэш под указанным ключевым именем, используя приоритет и время существования по умолчанию. Это эквивалентно применению синтаксиса коллекции на основе индекса и присваиванию нового ключевого имени
Cache.Insert(key, value,dependencies) Вставляет элемент в кэш под указанным ключевым именем, используя приоритет и время существования по умолчанию. Последний параметр содержит объект CacheDependency, связанный с другими файлами или кэшируемыми элементами и позволяющий объявлять данный элемент недействительным в случае их изменения
Cache.Insert(key, value, dependencies, absoluteExpiration, slidingExpiration) Вставляет элемент в кэш под указанным ключевым именем, используя приоритет и указанную политику устаревания (одну из двух). Эта версия метода Insert () используется наиболее часто
Cache.Insert(key, value, dependencies,absoluteExpiration, slidingExpiration, priority, onRemoveCallback) Позволяет конфигурировать все аспекты политики кэширования элемента, включая время существования, зависимости и приоритет. Вдобавок можно передать делегат, указывающий на метод, который должен быть вызван при удалении элемента из кэша

Если выбрано абсолютное устаревание, установите параметр slidingExpiration в TimeSpan.Zero.
Чтобы указать политику скользящего устаревания, установите параметр absoluteExpiration в DateTime.Max.

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

Для получение всех ключей объекта Cache можно воспользоваться перечисление коллекции с использованием класса DictionaryEntry.

Кэширование с помощью элементов управления источниками данных

Все элементы — SqlDataSource, ObjectDataSource и XmlDataSource — поддерживают встроенное кэширование данных.

Для поддержки кэширования все элементы управления источниками данных применяют одни и те же свойства, которые перечислены в табл.

Свойство Описание
EnableCaching Если равно true, то кэширование включено. Значением по умолчанию является false
CacheExpirationPolicy Использует значения из перечисления DataSourceCacheExpiry: Absolute — для абсолютного устаревания (когда указывается фиксированное время нахождение объекта в кэше) или Sliding — для скользящего устаревания (когда временное окно сбрасывается при каждом извлечении объекта из кэша)
CacheDuration Время в секундах нахождения объекта в кэше. Если используется скользящее устаревание, ременной предел сбрасывается каждый раз, когда объект извлекается из кэша. Значение по умолчанию — 0 (или Infinite) — позволяет хранить кэшированные элементы бесконечно
CacheKeyDependency и SqlCacheDependency Позволяет установить зависимость одного кэшированного элемента от другого (CacheKeyDependency) или от таблицы в базе данных (SqlCacheDependency).


Кэширование с помощью SqlDataSource

Когда вы включаете кэширование для элемента управления SqlDataSource, то кэ- шируете результаты Select Query. Однако если вы создаете запрос, принимающий параметры, то SqlDataSource будет кэшировать результаты отдельно для каждого набора значений этих параметров.

Кэширование с помощью ObjectDataSource

Кэширование ObjectDataSource работает с объектом данных, возвращенным SelectMethod. Если вы применяете параметризованный запрос, то ObjectDataSource делает различие между запросами с разными значениями параметров и кэширует их отдельно. К сожалению, кэширование ObjectDataSource обладает существенным ограничением — оно работает только тогда, когда метод выборки возвращает DataSet или DataTable. При возврате объекта любого другого типа возникает исключение NotSupportedException.

Зависимости кэша

С течением времени источники данных могут изменяться в ответ на некоторые действия. Однако если в коде применяется кэширование, вы можете оставаться в неведении об этих изменениях и продолжать использовать устаревшую информацию из кэша. Чтобы помочь в решении этой проблемы, ASP .NET поддерживает зависимости кэша. Эти зависимости позволяют сделать кэшированный элемент зависимым от другого ресурса, так что когда этот ресурс изменится, то кэшированный элемент будет автоматически удален.

Зависимости от файлов и элементов кэша

Чтобы создать зависимость кэша, необходимо построить объект CacheDependency и затем использовать его при добавлении зависимого кэшированного элемента. Например, в следующем коде создается кэшированный элемент, который будет автоматически удален из кэша при изменении, удалении или перезаписи XML -файла:

Если установить зависимость CacheDependency на папку, она будет отслеживать добавление, удаление и модификацию любого файла в этой папке. Модификация вложенной папки (например, переименование, создание или удаление) также нарушает зависимость. Однако более глубокие изменения в дереве каталогов (вроде добавления файла во Сложенную папку или создания вложенной папки второго уровня) не имеют никакого эффекта.

Еще один конструктор принимает массив имен файлов и массив ключей кэша. В следующем примере этот конструктор используется для создания элемента, который зависит от другого элемента в кэше:

Если после этого элемент Cache [«Keyl»] изменится или будет удален из кэша, элемент Cache [«Keyl»] удалится автоматически.

Агрегатные зависимости

Класс AggregateCacheDependency может группировать любое количество объектов CacheDependency. Все, что необходимо сделать — добавить необходимые объекты CacheDependency в массив с применением метода AggregateCacheDependency.Add(). Ниже приведен пример, в котором кэшированный элемент зависит от двух файлов:

Метод обратного вызова при удалении элемента

В приведенном ниже примере метод обратного вызова применяется для создания двух зависимых друг от друга элементов — трюк, который был бы невозможен с одними только зависимостями. Два элемента вставляются в кэш, и когда любой из них удаляется, его метод обратного вызова удаляет второй.

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

DependencyChanged Удален, поскольку зависимость от файла и ключа изменилась
Expired Удален по причине устаревания (в соответствии с его политикой абсолютного или скользящего устаревания)
Removed Удален программно вызовом метода Remove либо метода Insert с тем же ключом
Underused Удален, поскольку среда ASP .NET приняла решение, что объект не достаточно важен, а требуется освободить память

Уведомления кэша SQL

Как работают уведомления кэша

С помощью Service Broker можно принимать уведомления об определенных событиях базы данных. Наиболее прямой подход заключается в применении команды CREATE EVENT NOTIFICATION для указания события, которое необходимо наблюдать. Однако .NET предлагает высокоуровневую модель, интегрированную с ADO.NET. Используя эту модель, вы просто регистрируете команду запроса, a .NET автоматически инструктирует SQL Server о необходимости отправки уведомлений о любых операциях, которые могут повлиять на результат этого запроса. ASP .NET предлагает даже еще более высокоуровневую модель, построенную на этой инфраструктуре и позволяющую автоматически объявить недействительными кэшированные элементы, когда становится недействительным запрос.

Мониторинг изменений в базе данных SQL Server

Включение уведомлений

Единственный конфигурационный шаг, который должен быть выполнен — установка для базы данных флага ENABLEBROKER. Это можно сделать, запустив следующий код SQL (предполагая, что используется база данных Northwind):

Уведомления работают с запросами SELECT и хранимыми процедурами. Однако на синтаксис SELECT накладываются некоторые ограничения. Чтобы правильно поддерживать уведомления, команда должна отвечать следующим требованиям.

Как работает ASP.NET Cache?

Я заинтересован в использовании кэша ASP.NET для уменьшения времени загрузки. Как мне это сделать? С чего начать? И как работает кеширование?

Илон Маск рекомендует:  Что такое код intr

4 ответа

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


В веб-приложениях ASP.NET существует 3 типа общих методов кэширования:

  • Кэширование вывода страницы (уровень страницы)
  • Страница выхода частичной страницы (конкретные элементы страницы)
  • Программирование или кэширование данных

Кэширование вывода

Кэширование вывода на уровне страницы кэширует html страницы, так что каждый раз, когда страница ASP.NET запрашивает ее, сначала проверяет выходной кеш. Вы можете изменять эти запросы по входным параметрам (VaryByParam), поэтому страница будет кэшироваться только для пользователей, где >

Кэширование частичной страницы

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

Кэширование данных

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

Кэширование уровня предприятия

Следует отметить, что существует множество архитектур кэширования уровня предприятия, которые стали использовать кэширование эффективности. Memcache для .net и Velocity (теперь App Fabric) это пара.

В целом

Вы не можете делать полные заявления о том, что нужно, и не должны кэшировать, потому что каждое приложение отличается. Тем не менее, вы можете сделать несколько обобщений, которые имеют истинное значение МОСТ. Статические элементы, такие как изображения и содержимое, в порядке кэширования. Даже динамическая страница, которая забивается, стоит кэшировать в течение 5-10 секунд, она создаст мир, имеющий значение для вашего веб-сервера.

Кэширование данных в ASP.NET MVC 3

У меня есть 3 приложения ASP.NET MVC, что это в основном просто набор веб-сервисов. Эти веб-сервисы подвергаются набором действий контроллера. Каждое действие контроллера запрашивает мою базу данных. Потому что мои данные меняются редко, а несвежие данные не является проблема, я думал, я бы реализовать некоторые кэширования для повышения производительности. Мои цели:

  1. Никогда не кэшировать ответ пользователю.
  2. Кэш записи базы данных до 24 часов. Если 24 часа прошло, попал в базу данных снова.

Имеет ли это смысл? Я знаю, как предотвратить ответ от кэширования. Я просто использовать следующее:

Тем не менее, я не уверен, как кэшировать мои записи базы данных в памяти до 24 часов. Кто-нибудь есть какие-либо предложения о том, как это сделать? Я даже не знаю, где искать.

Вы можете использовать System.Runtime.Caching пространство имен (или кэш ASP.NET, но это старше и может быть использован только в веб — приложениях).

Вот пример функции, которые вы можете использовать, чтобы обернуть вокруг вашего текущего механизма поиска данных. Вы можете изменить параметры в MemoryCache.Add контролировать, сколько это кэшируются, но вы просили 24h выше.

Как упомянуто @Bond, вы можете также посмотреть на использовании SQL Cache Завис, если данные вы кэширование, вероятно, изменится в течение 24 часов. Если это довольно статичное, хотя, это будет делать то, что вы просили.

То, что вы говорите о не совсем MVC ответственность. ASP.Net позволяют cahce только то, что он производит (и это они Свои замечания, obviosly).

Если вы хотите кэшировать данные, которые он может быть лучше Cachet это такое же место, она была произведена — где-то в BL или Data Layer.

Вы можете сделать что-то вроде этого:

String data представляет фактические данные здесь. После добавления этого класса заменить GetData() методы с DataCacher.Data .

Надеюсь, что это помогает или, по крайней мере, ведет к некоторому дальнейшему мышления.

Рамки MVC является сохранение агностик. Там нет встроенных средств для хранения данных, поэтому нет никаких встроенных средств для кэширования хранимых данных.


OutputCache Атрибут может использоваться для кэширования ответа сервера. Но вы явно указано , что это не то , что вы хотите сделать.

Тем не менее, вы все равно можете быть в состоянии использовать встроенный в систему, OutputCache если вы хотите , чтобы оставаться в рамках MVC. Рассмотрим обнажая данные , которые вы хотите кэшировать в результате JSON

Строка JSON в /ControllerName/GetMyData кэшируются в течение 24 часов, поэтому фактический запрос будет побежал только один раз в день. Это означает , что вы должны были бы осуществить вызов AJAX на вашей последней странице, или сделайте другой HTTP вызов с вашего сервера. Ни один из тех , являются идеальными.

Я бы искать другое решение вашей проблемы вне рамок MVC. Рассмотрим Memcached , который был создан именно для этой цели.

Плюсы / минусы разных ASP.NET параметры кэширования

недавно я задал вопрос о кэшировании данных приложения в ASP.NET приложение MVC WebAPI и это привело меня к новому вопросу. Каковы плюсы / минусы различных методов кэширования, доступных в ASP.NET?

Использование Статического Элемента Переменные:

Я уверен, что есть и другие, и я знаю, что все они технически хранят данные в memory. so любая идея, что я должен использовать для ASP.NET MVC webapi?

3 ответа:

каждая технология/методы кэширования имеют свой собственный набор функций. Эти особенности могут казаться недостатком в одном прикладном требовании, но могут быть выгодными в других прикладных требованиях.

короче говоря, в зависимости от ваших требований решите, какая технология кэширования и какие функции лучше всего подходят для вас.

For example, Let us discuss some client side Caching techniques .

MSDN говорит, что мы также можем использовать HiddenField хранить только небольшие суммы часто изменяющихся данных в скрытых полях, потому что эти данные включены в roundtrips к серверу на каждой обратной передаче.

функции: снижает нагрузку на сервер, сохраняя информацию о странице с помощью параметров на стороне клиента.

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

таким образом, можно или нельзя использовать эту функцию всегда, поскольку соображения безопасности тоже там.

Consider one more example , Page Output caching : он имеет 2 типа, кэширование вывода страниц и кэширование фрагментов страниц.

кэширование вывода страницы кэширует всю веб-страницу и подходит только тогда, когда содержимое этой страницы довольно статично. Если части страницы изменяются, вы можете обернуть статические разделы как пользовательские элементы управления и кэшировать пользовательские элементы управления с помощью фрагмента страницы кэширование.

And one last comment on Application vs HttpRuntime.cache :

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

  • переменные приложения являются общими переменными для всех пользователей веб-приложения
  • переменные приложения ведут себя как статические переменные, и они заменяют статические переменные, поскольку статические переменные без состояния в веб-приложениях
  • только общие значения должны сохраняться в переменных приложения, и как только они не используются, они должны быть удалены явно.

Cache :можно получить значительные улучшения производительности в ASP.NET приложения путем кэширования часто запрашиваемых объектов и данных в любом Application или Cache классы. В то время как Cache класс, безусловно, предлагает гораздо больше гибкости и контроля, это только кажется предложите предельное преимущество по отоношению к увеличенному объем над Application класс для кэширования. Было бы очень трудно разработать схему тестирования, которая могла бы точно измерить потенциальные преимущества Cache встроенное управление класса менее используемых объектов через процесс очистки в отличие от того, что приложение не предлагает эту функцию. Разработчик должен принять решение в этом случае и должен быть основан на потребностях и удобстве проекта и свои картины использования. Проверьте этой ссылке дополнительные.

см. этой статье для полного отличного объяснения всех технологий кэширования в Asp.net с discusiion на особенностях каждой технологии.

кроме того, эти 2 ссылки являются отличным источником для начала с:

о MemoryCache vs ASP.NET кэш: они обеспечивают очень похожую функциональность. В Ан ASP.NET 4 приложения, я бы вообще предпочел ASP.NET кэш, если ни по какой другой причине, то из-за ошибка в .NET 4, который, по-видимому, исправлен в .NET 4.5.

статические поля подходят для хранения общих данных, для которых не требуется политика истечения срока действия.

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


при использовании Web API ваш первый выбор для кэширования всегда должен заключаться в установке заголовков кэширования в HTTP-ответе. HttpResponseMessage.CacheControlHeader .

ваши последние варианты должны быть все, что зависит от HttpContext или HttpRuntime , так как это свяжет вас с конкретными хостами. Приложения Web API должны быть построены независимо от их хоста.

Обзор кэширования

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

Что такое кэширование?

В сфере вычислительной обработки данных кэш – это высокоскоростной уровень хранения, на котором требуемый набор данных, как правило, временного характера. Доступ к данным на этом уровне осуществляется значительно быстрее, чем к основному месту их хранения. С помощью кэширования становится возможным эффективное повторное использование ранее полученных или вычисленных данных.

Как работает кэширование?

Данные в кэше обычно хранятся на устройстве с быстрым доступом, таком как ОЗУ (оперативное запоминающее устройство), и могут использоваться совместно с программными компонентами. Основная функция кэша – ускорение процесса извлечения данных. Он избавляет от необходимости обращаться к менее скоростному базовому уровню хранения.

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

Обзор кэширования

ОЗУ и работающие в памяти сервисы. Поскольку ОЗУ и работающие в памяти сервисы обеспечивают высокие показатели скорости обработки запросов, или IOPS (количество операций ввода-вывода в секунду), кэширование повышает скорость извлечения данных и сокращает расходы при работе в больших масштабах. Чтобы обеспечить аналогичный масштаб работы с помощью традиционных баз данных и оборудования на базе жестких дисков, требуются дополнительные ресурсы. Использование этих ресурсов приводит к повышению расходов, но все равно не позволяет достигнуть такой низкой задержки, какую обеспечивает кэш в памяти.

Области применения. Кэш используется на разных технологических уровнях, включая операционные системы, сетевые уровни, в том числе сети доставки контента (CDN) и DNS, интернет-приложения и базы данных. С помощью кэширования можно значительно сократить задержку и увеличить количество операций ввода-вывода в секунду для рабочей нагрузки многих приложений с большим количеством операций чтения, таких как порталы вопросов и ответов, игры, сервисы обмена мультимедийными материалами и социальные сети. Информация в кэше может включать результаты запросов к базе данных, сложных вычислений, запросы и ответы API, а также интернет-артефакты, такие как HTML, JavaScript и файлы изображений. Рабочие нагрузки, требующие больших вычислительных мощностей для обработки наборов данных, например сервисы рекомендаций и высокопроизводительное вычислительное моделирование, тоже могут эффективно использовать уровень данных в памяти в качестве кэша. В приложениях такого рода доступ к огромным наборам данных осуществляется в реальном времени на кластерах машин, которые могут охватывать сотни узлов. Скорость работы базового оборудования, осуществляющего обработку данных в дисковом хранилище, представляет собой серьезное препятствие для таких приложений.

Илон Маск рекомендует:  dir в HTML

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

Рекомендации по кэшированию. При реализации уровня кэша необходимо принимать во внимание достоверность кэшируемых данных. Эффективный кэш обеспечивает высокую частоту попаданий, то есть наличия в кэше запрашиваемых данных. Промах кэша происходит, когда запрашиваемых данных в кэше нет. Для удаления из кэша неактуальных данных применяются такие механизмы, как TTL (время жизни). Следует также понимать, требуется ли для среды кэширования высокая доступность. Если она необходима, можно использовать сервисы в памяти, такие как Redis. В ряде случаев уровень в памяти можно использовать как отдельный уровень хранения данных, в отличие от кэширования из основного хранилища. Чтобы решить, подходит ли такой вариант, необходимо определить для данных в сервисе в памяти соответствующие значения RTO (требуемое время восстановления, то есть сколько времени требуется системе на восстановление после сбоя) и RPO (требуемая точка восстановления, то есть последняя восстанавливаемая точка или транзакция). Для соответствия большинству требований RTO и RPO можно применять характеристики и проектные стратегии разных сервисов в памяти.

Ускорение загрузки контента с веб-сайтов (для браузеров или мобильных устройств)

Уровень Клиентская часть DNS Интернет Приложение База данных
Пример использования Разрешение доменных имен в IP-адреса Ускорение загрузки контента с веб-серверов и серверов приложений. Управление веб-сессиями (на стороне сервера) Повышение производительности приложений и скорости доступа к данным Сокращение задержек, связанных с обработкой запросов к базе данных
Технологии Управление кэшированием с помощью HTTP-заголовков (браузеры) DNS-серверы Управление кэшированием с помощью HTTP-заголовков (CDN, обратные прокси-серверы, интернет-ускорители, хранилища пар «ключ-значение») Хранилища пар «ключ-значение», локальный кэш Буфер базы данных, хранилища пар «ключ-значение»
Решения В зависимости от браузера Amazon Route 53 Amazon CloudFront, ElastiCache для Redis, ElastiCache для Memcached, решения партнеров Инфраструктуры приложений, ElastiCache для Redis, ElastiCache для Memcached, решения партнеров ElastiCache для Redis, ElastiCache для Memcached

Кэширование с помощью Amazon ElastiCache

Веб-сервис Amazon ElastiCache упрощает развертывание, эксплуатацию и масштабирование в облаке хранилища или кэша в памяти. Сервис повышает производительность интернет-приложений, позволяя получать информацию из быстрых управляемых хранилищ данных, размещенных в памяти, а не из более медленных баз данных, размещенных на дисках. Информацию о том, как реализовать эффективную стратегию кэширования, см. в этом техническом описании по кэшированию в памяти.

Преимущества кэширования

Повышение производительности приложений

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

Сокращение стоимости базы данных

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

Сокращение нагрузки на серверную часть

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

Прогнозируемая производительность

Распространенной проблемой современных приложений является необходимость справляться с периодами пиковой нагрузки. С этим сталкиваются социальные приложения в дни крупных спортивных соревнований или выборов, интернет-магазины в дни распродаж и т. д. Рост нагрузки на базу данных приводит к увеличенной задержке при получении ответа на запрос, что негативно сказывается на общей производительности приложения. Эта проблема эффективно решается за счет высокой пропускной способности кэша в памяти.


Устранение «горячих точек» базы данных

Во многих приложениях бывают ситуации, когда небольшая часть массива данных, например страница знаменитости или популярный продукт, получает больше запросов, чем другие элементы массива. Это может привести к появлению в базе данных «горячих точек» и избыточному выделению ресурсов сервера на основании установленных требований к пропускной способности для наиболее часто запрашиваемых данных. Если хранить часто используемые ключи в кэше в памяти, исчезает необходимость в выделении лишних ресурсов, а доступ к часто запрашиваемым данным остается быстрым и надежным.

Повышение пропускной способности чтения (IOPS)

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

How to cache data in a MVC application

I have read lots of information about page caching and partial page caching in a MVC application. However, I would like to know how you would cache data.

In my scenario I will be using LINQ to Entities (entity framework). On the first call to GetNames (or whatever the method is) I want to grab the data from the database. I want to save the results in cache and on the second call to use the cached version if it exists.

Can anyone show an example of how this would work, where this should be implemented (model?) and if it would work.

I have seen this done in traditional ASP.NET apps , typically for very static data.

15 Answers 15

Reference the System.Web dll in your model and use System.Web.Caching.Cache

A bit simplified but I guess that would work. This is not MVC specific and I have always used this method for caching data.

Here’s a nice and simple cache helper class/service I use:

Usage:

Cache provider will check if there’s anything by the name of «cache id» in the cache, and if there’s not, it will call a delegate method to fetch data and store it in cache.

Example:

I’m referring to TT’s post and suggest the following approach:

Reference the System.Web dll in your model and use System.Web.Caching.Cache

You should not return a value re-read from the cache, since you’ll never know if at that specific moment it is still in the cache. Even if you inserted it in the statement before, it might already be gone or has never been added to the cache — you just don’t know.

So you add the data read from the database and return it directly, not re-reading from the cache.

For .NET 4.5+ framework

add reference: System.Runtime.Caching

add using statement: using System.Runtime.Caching;

In the .NET Framework 3.5 and earlier versions, ASP.NET provided an in-memory cache implementation in the System.Web.Caching namespace. In previous versions of the .NET Framework, caching was available only in the System.Web namespace and therefore required a dependency on ASP.NET classes. In the .NET Framework 4, the System.Runtime.Caching namespace contains APIs that are designed for both Web and non-Web applications.

Steve Smith did two great blog posts which demonstrate how to use his CachedRepository pattern in ASP.NET MVC. It uses the repository pattern effectively and allows you to get caching without having to change your existing code.

In these two posts he shows you how to set up this pattern and also explains why it is useful. By using this pattern you get caching without your existing code seeing any of the caching logic. Essentially you use the cached repository as if it were any other repository.

AppFabric Caching is distributed and an in-memory caching technic that stores data in key-value pairs using physical memory across multiple servers. AppFabric provides performance and scalability improvements for .NET Framework applications. Concepts and Architecture

Extending @Hrvoje Hudo’s answer.

Code:

Examples

Single item caching (when each item is cached based on its ID because caching the entire catalog for the item type would be too intensive).

Кэширование данных в ASP.Net

Мне нужно заполнить несколько выпадающих ящиков из некоторых справочных данных. Список городов, Список стран и т.д. Мне нужно заполнить его в различных веб-формах. Я думаю, мы должны кэшировать эти данные в нашем приложении, чтобы мы не попадали в базу данных по каждой форме. Я новичок в кэшировании и ASP.Net. Пожалуйста, предложите мне, как это сделать.

Я всегда добавляю следующий класс ко всем моим проектам, которые дают мне легкий доступ к объекту Cache. Реализация этого, после ответа Хасана Хана, будет хорошим способом.

Из вашего другого вопроса я прочитал, что вы используете трехслойную архитектуру с dal, бизнес-и презентационным уровнем.

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

Например: если у вас есть интерфейс IUserRepository, тогда класс UserRepository будет реализовывать его и добавлять/удалять/обновлять записи в db с помощью методов, тогда вы также можете иметь CachedUserRepository, который будет содержать экземпляр объекта UserRepository, а в методах get он сначала будет изучать кеш против некоторого ключа (полученный из параметров метода), и если элемент найден, он возвращает его, иначе вы вызываете метод на внутреннем объекте; получить данные; добавьте в кеш и верните его.

Понравилась статья? Поделиться с друзьями:
Кодинг, CSS и SQL