Asp кэшируйте данные на диске веб сервера

Содержание

Asp кэшируйте данные на диске веб сервера

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

В платформе .NET Framework предоставляются классы, позволяющие использовать средства кэширования в приложениях ASP.NET. Эти классы определяются в пространстве имен System.Runtime.Caching .

Пространство имен System.Runtime.Caching — это новое пространство имен в платформе .NET Framework 4. Это пространство имен обеспечивает доступность кэширования для всех приложений платформы .NET Framework.

В данном пошаговом руководстве показано использование функции кэширования, которая доступна в платформе .NET Framework в качестве компонента приложения ASP.NET. В этом руководстве кэшируется содержимое текстового файла.

В данном пошаговом руководстве представлены следующие задачи:

Создание веб-сайта ASP.NET.

Добавление ссылки на платформу .NET Framework 4.

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

Реализация политики вытеснения записи кэша.

Отслеживание пути к кэшированному файлу и уведомление кэша об изменениях отслеживаемых элементов.

Для выполнения этого пошагового руководства потребуется следующее.

Microsoft Visual Studio 2010.

Текстовый файл с небольшим объемом текста. Содержимое этого текстового файла будет отображено на веб-странице.

Начнем с создания веб-сайта ASP.NET.

Примечание

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

Создание веб-узла ASP.NET

Запустите Visual Studio 2010.

В меню Файл выберите пункт Новый веб-узел . (Если этот пункт отсутствует, выберите команду Создать , а затем — Веб-узел .)

Откроется диалоговое окно Новый веб-узел .

В разделе Установленные шаблоны щелкните элемент Visual Basic или C# , а затем щелкните пункт Веб-сайт ASP.NET .

В поле Расположение в Интернете выберите пункт Файловая система и введите имя папки, в которой будут храниться страницы веб-сайта. Например, введите имя папки C:\Websites\AppCaching и нажмите кнопку ОК .

Visual Studio создаст веб-проект, включающий стандартные функциональные возможности для макета (главную страницу, страницы содержимого Default.aspx и About.aspx и каскадную таблицу стилей), технологии Ajax (файлы клиентских скриптов) и проверки подлинности (членство в ASP.NET). По умолчанию при создании новой страницы Visual Web Developer отображает страницу в представлении Исходный код , где можно видеть HTML-элементы страницы.

Следующий шаг — добавление текстового файла, который требуется использовать, в текущий проект веб-сайта.

Добавление текстового файла в проект

В окне Обозреватель решений щелкните правой кнопкой мыши имя проекта и выберите команду Добавить существующий элемент .

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

Чтобы использовать пространство имен System.Runtime.Caching в приложении ASP.NET, необходимо добавить ссылку на это пространство имен.

Добавление ссылки на веб-сайт

В окне Обозреватель решений щелкните правой кнопкой мыши имя веб-сайта и выберите команду Добавить ссылку .

Перейдите на вкладку .NET , выберите System.Runtime.Caching и нажмите кнопку ОК .

Следующий шаг — добавление кнопки и элемента управления Label на страницу. Будет создан обработчик событий для события Click кнопки. Позже будет добавлен код, обеспечивающий при нажатии кнопки отображение кэшированного текста в элементе управления Label .

Добавление элементов управления на страницу

Откройте страницу Default.aspx или перейдите к ней.

С вкладки Стандартная на панели элементов перетащите элемент управления Button на страницу Default.aspx.

В окне Свойства задайте для свойства Text элемента управления Button значение Get From Cache. Примите свойство идентификатора по умолчанию.

С вкладки Стандартная на панели элементов перетащите элемент управления Label на страницу. Примите свойство идентификатора по умолчанию.

Теперь будет добавлен код для выполнения следующих задач.

Создание экземпляра класса кэша (будет создан экземпляр объекта кэша).

Указание того, что для отслеживания изменений в текстовом файле кэш использует объект HostFileChangeMonitor .

Чтение текстового файла и кэширование его содержимого в виде записи кэша.

Отображение содержимого кэшированного текстового файла.

Создание объекта кэша

Дважды нажмите кнопку, чтобы создать обработчик событий в файле Default.aspx.cs или Default.aspx.vb.

В верхней части файла (перед объявлением класса) добавьте указанные ниже операторы Imports (Visual Basic) или using (C#).

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

ObjectCache — это базовый класс, предоставляющий методы для реализации объекта кэша в памяти.

Внимание

В ASP.NET 4 кэширование реализуется с помощью класса ObjectCache .

Добавьте следующий код для чтения содержимого записи кэша с именем filecontents

Добавьте следующий код для проверки наличия записи кэша с именем filecontents

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

В блоке if/then добавьте следующий код, чтобы создать новый объект CacheItemPolicy , указывающий, что срок действия кэша истекает через 10 секунд.

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

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

Метод HttpServerUtilityMapPath возвращает путь к корню текущего веб-сайта.

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

Объект HostFileChangeMonitor отслеживает путь к текстовому файлу и при появлении изменений уведомляет кэш. В этом примере срок действия записи кэша автоматически истечет при изменении содержимого файла.

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

Отметка даты и времени добавляется для определения времени окончания срока действия записи кэша.

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

Указываются сведения о том, как должна быть удалена запись кэша путем передачи объекта CacheItemPolicy в качестве метода с параметром Set .

Добавьте после блока if/then следующий код, чтобы отобразить кэшированное содержимое файла в элементе управления Label .

Теперь приложение можно протестировать.

Проверка кэширования на веб-сайте ASP.NET

Нажмите CTRL+F5, чтобы запустить приложение.

Нажмите кнопку Получить из кэша .

В метке отображается кэшированное содержимое текстового файла. Обратите внимание на отметку времени в конце файла.

Снова нажмите кнопку Получить из кэша .

Отметка времени не изменилась. Это означает, что отображается кэшированное содержимое.

Подождите 10 секунд или более и снова нажмите кнопку Получить из кэша .

Теперь отображается новая отметка времени. Это означает, что политика допускает истечение срока действия кэша через 10 секунд и что отображается новое кэшированное содержимое.

В текстовом редакторе откройте текстовый файл, добавленный в проект веб-сайта. Пока не вносите никаких изменений.

Снова нажмите кнопку Получить из кэша .

Снова обратите внимание на отметку времени.

Внесите изменение в текстовый файл и сохраните файл.

Снова нажмите кнопку Получить из кэша .

Теперь отметка времени сразу же изменяется. Это означает, что после внесения изменения монитор изменений файла узла сразу же удалил элемент кэша.

Примечание

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

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

Как кэшировать изображения в памяти на веб-сервере для веб-приложение ASP.NET MVC?

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

1) Изображения доступны из URL, как http://www.site.com/album/1.jpg . Как изображения , хранящиеся в памяти? Они собираются , чтобы быть в форме потока памяти?

2) Как получить доступ изображения из памяти и отправить на веб-pagee? Теперь веб-страницы будут использовать URL изображения непосредственно вставлять изображения в теге.

Если изображения только статические файлы на диске, то Beepcake правильно, что IIS уже будет кэшировать часто используемые изображения и служит их из памяти. Использование отдельных серверов кэширования не должно быть быстрее, чем служить IIS изображения из памяти — он получил больше, чтобы сделать с масштабируемостью. Если у вас есть большая ферма серверов, это означает, что у вас есть группа серверов только занимающихся кодами и группа серверов только дело со статическими изображениями. Кроме того, если у вас слишком много информации для одного сервера кэшировать все то вы можете маршрутизировать запросы, так что каждый из ваших десяти серверов кэширует другой 10% от содержания. Это должно быть намного лучше, чем просто каждый кэш сервера тот же самый используемый 10% от содержания.

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

Для реализации я бы настроить страницу, которая взяла имя файла изображения и служил его либо с диска или из asp.net в кэш-памяти.

Если вы хотите действительно хорошую работу, я хотел бы предложить Amazon CloudFront. кэширование края даст вам лучшую производительность, чем кэширование памяти, и CloudFront работает Nginx, что значительно лучше, чем IIS при статических файлах (среди прочего).

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

Использование кэширования в 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 , чье значение , в свою очередь , отличается от уже сохраненного в кэше.

Кэширование ответа¶

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

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

Основным HTTP заголовком является Cache-Control . Спецификация HTTP 1.1 определяет несколько опций для директив. Вот три основные директивы:

public Говорит, что ответ может храниться в кэше. private Говорит, что ответ предназначен для одного пользователя и кэш не должен быть общим. no-cache Кэш не должен использоваться.

Кэширование ответов не кэширует ответы для веб сервера. Это отличается от кэширования выходных данных, которое кэширует ответы in-memory на сервере в более ранних версиях ASP.NET и ASP.NET MVC. В следующих релизах ASP.NET MVC 6 планируется добавить кэширование выходных данных.

Дополнительные HTTP заголовки, используемые для кэширования, включают в себя Pragma и Vary . См. Кэширование в HTTP.

Атрибут ResponseCache¶

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

Duration int Максимальная длительность (в секундах), за которую должен быть закэширован ответ. Required, пока NoStore не является true . Location ResponseCacheLocation Местоположение кэшированного ответа. Может быть Any , None или Client . По умолчанию Any . NoStore bool Определяет, должно ли храниться значение, и переписывает другие свойства атрибута. При true игнорируется Duration , а Location игнорируется при значениях, иных чем None . VaryByHeader string Для ответа устанавливается заголовок vary . CacheProfileName string Определяет имя профиля кэша. Order int Порядок использования фильтров (из IOrderedFilter).

ResponseCacheAttribute используется для настройки и создания (через IFilterFactory) ResponseCacheFilter, который записывает соответствующие HTTP заголовки в ответ. Фильтр сперва удалит существующие заголовки для«Vary«, Cache-Control` и «Pragma , а затем запишет соответствующие заголовки, основываясь на свойствах, определенных в ResponseCacheAttribute .

Заголовок Vary ¶

Этот заголовок записывается, только если установлено свойство VaryByHeader .

NoStore и Location.None ¶

NoStore — это специальное свойство, которое переопределяет большинство других свойств. Если это свойство является true, заголовок Cache-Control будет установлен на “no-store”. Кроме того, если Location установлено на None , тогда Cache-Control будет установлен на “no-store, no-cache” и Pragma будет установлено на no-cache . (Если NoStore является false и Location является None , тогда Cache-Control и Pragma будут установлены на no-cache ).

Лучше всего устанавливать NoStore на true для страниц с ошибками. Вы не захотите отвечать на запрос пользователя ответом с ошибкой, сгенерированным предыдущим пользователем, и такие ответы могут включать в себя чувствительные данные, которые не стоит размещать на промежуточных серверах. Например:

И вот результат:

Location и Duration¶

При кэшировании у Duration должно быть установлено положительное значение, а Location должно быть Any (по умолчанию) или Client . В данном случае заголовок Cache-Control будет установлен на значение location, за которым следует “max-age” ответа.

Опции Location Any и Client передают в заголовок Cache-Control значения public и private . Как упоминалось ранее, установка Location на None приведет к тому, что Cache-Control и Pragma будут no-cache .

Вот заголовки, созданные при настройке Duration и базовом значении Location .

Produces the following headers:

Профили кэша¶

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

Ссылка на профиль:

Атрибут ResponseCache может применяться к методам действия и контроллерам. Атрибуты на уровне метода переопределяют настройки, указанные для атрибутов на уровне класса.

Кэширование соединений с веб-сервером

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

Каждый раз на проходение этапа.

Определения = Новый WSОпределения

Прокси = Новый WSПрокси

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

Есть ли возможность кэшировать именно соединение более 20 секунд?

Какие еще существуют варианты решениия проблемы?

Использование веб-сервиса возможно как в режиме толстого клиента, так и в тонком клиенте.

Примечание

Лефмихалыч

(9) Скорее всего, его и буду использовать (если речь идет о хранении данных подключения).
Думаю о том, как это делать без доработки конфигурации получателя.
В толстом клиенте все просто — сохранить в клиенсткую переменную. А в толстом — без кэшируемого модуля.

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

Лефмихалыч

(13) долго что ли заставить базу-источник самостоятельно инициировать обмен с приемником, когда данные изменились?

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

Четыре уровня кэширования в сети: клиентский, сетевой, серверный и уровень приложения

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

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

клиентский;
сетевой;
серверный;
уровень приложения.

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

Кэш на клиентском уровне

Заголовки HTTP отвечают за определение возможности кэширования ответа и за определение срока хранения данных. Следующий пример заголовка Cache-control указывает, что ответ может находиться в кэше в течение 7 дней. Браузер отправит повторный запрос на хранение данных, если срок хранения истечёт или пользователь целенаправленно обновит страницу.

Запрос и ответ, которые могут быть кэшированы в течение 604800 секунд.

Ответ также может включать заголовок Last-Modified или Etag . Эти заголовки нужны для проверки возможности повторного использования данных. Статус ответа 304 указывает, что содержимое не изменилось и повторная загрузка не требуется. Обратите внимание на парные заголовки Last-Modified и If-Modified-Since , а также на даты ниже:

Ответ с заголовком «Last-Modified» и последующим запросом с его использованием.

Заголовок Etag используется с If-None-Match аналогичным образом для обмена кодами ответа при определении изменений в контенте, если они имеются.

Сайт с продуманными HTTP-заголовками обретёт больший успех у пользователей. Кроме того, браузер сэкономит время и пропускную способность.

Кэш на сетевом уровне

Согласно Википедии, Сеть Доставки Контента (CDN) — географически распределённая сетевая инфраструктура, позволяющая оптимизировать доставку и дистрибуцию контента конечным пользователям в сети Интернет. Иначе говоря, CDN — это распределённое хранение и использование кэша.

Директива HTTP-заголовка Cache-control: public позволяет различным частям сети кэшировать ответ. С помощью заголовка Cache-Control: public, max-age=31536000 находят ресурсы, которые хранятся в течение одного года.

Возможно, вы уже знакомы с другими директивами заголовков. Существует также ещё один мощный заголовок, для обработки аутентифицированных и других видов динамических ответов.

Кэш на серверном уровне

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

Первый подход к более быстрым ответам и экономии ресурсов — настройка кэш-сервера между приложением и клиентом.

Клиенты, запрашивающие одно и то же содержимое на прокси-сервере.

Такие инструменты, как Varnish, Squid и nginx кэшируют изображения, скрипты и прочее содержимое, которое требуется пользователям. Следующая настройка nginx собирает кэш, опираясь только на HTTP-заголовки в приложении.

Существует ещё одна директива, которая называется proxy_cache_lock , которая позволяет прокси-серверу делегировать только первый из похожих клиентских запросов за один раз для приложения. Если директива установлена, клиенты будут получать ответ при возврате первого запроса.

Множество клиентов, запрашивающих одно и то же содержимое одновременно.

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

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

В руководстве по кэшированию с NGINX и NGINX Plus содержится более подробная информация и параметры конфигурации.

Кэш на уровне приложения

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

Мемоизация

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

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

Интеллектуальное кэширование в памяти

В приведённом выше коде используется API кэширования Rails для хранения и повторного использования метки категории в течение одной минуты во время обработки запросов. Ключом кэша для идентификации данных является category_id . Этот метод используется для экономии ресурсов, времени и уменьшения объёма запросов к внешней службе меток категорий.

Многие библиотеки предоставляют этот шаблон, но память приложения — не бесконечный ресурс. Например, менеджер кэша для Node не управляет объёмом потребляемой памяти. Также это может стать проблемой, если ваше приложение кэширует данные в больших объёмах, потребляя всю доступную память.

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

Совместное кэширование

Умение обращаться с растущим количеством пользователей и запросов — важный объект веб-разработки. Один из способов масштабирования приложения — добавление экземпляров приложения (горизонтальное масштабирование). Как вы, наверно, догадались, простой кэш в памяти не может использоваться несколькими экземплярами.

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

Хранилище со значениями ключей, такое как Memcached или Redis, может использоваться для совместного распределения данных кэша между экземплярами приложения. Эти инструменты имеют разные алгоритмы для сокращения количества кэшированных данных. Хранилища кэша также могут быть устойчивы к ошибкам с репликацией и хранением данных. Алгоритмы настолько сильно различаются, что Netflix создала свой собственный инструмент.

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

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

Заключение

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

Настройка параметров кэша для веб-приложения в SharePoint Server Configure cache settings for a web application in SharePoint Server

Применимо к: да да да нет SharePoint Online APPLIES TO: 2013 2020 2020 SharePoint Online

В этой статье описано, как настроить кэш больших двоичных объектов на диске, профили кэша вывода страниц и кэш объектов для веб-приложения в SharePoint Server. This article describes how to configure the disk-based BLOB cache, the page output cache profiles, and the object cache for a web application in SharePoint Server.

Включение и настройка кэша BLOB, а также изменение конфигурации для профилей кэша вывода страниц и кэша объектов осуществляются в файле Web.config того веб-приложения, к которому требуется применить эти изменения. Изменения, вносимые в файл Web.config, применяются ко всем семействам сайтов в данном веб-приложении. You enable and configure the BLOB cache, and make configuration changes to the page output cache profiles and the object cache in the Web.config file in the web application to which you want to apply those changes. The changes you make to the Web.config file will be applied to all site collections within the web application.

SharePoint Server включает в себя мониторы производительности кэша, которые позволяют проверить правильность параметров кэша фермы, а также то, что кэширование выполняется с максимальной производительностью. SharePoint Server includes cache performance monitors that let you verify that the farm cache settings are correct and that the caching is running at maximum performance. Дополнительные сведения см. в статье мониторинг производительности кэша в SharePoint Server 2020. For more information, see Monitor cache performance in SharePoint Server 2020.

Настройка профилей кэша вывода страниц и кэша объектов на уровне веб-приложения переопределяет любую конфигурацию, примененную администраторами сайтов на уровне семейства сайтов или ниже. Configuring the page output cache profiles and the object cache at the web application level will supersede any configuration that was made by site administrators at the site collection level or below.

В некоторых ситуациях кэш BLOB может рассинхронизироваться с контентом. There may be times when the BLOB cache becomes out of sync with the content. Например, после восстановления базы данных контента кэш BLOB потеряет синхронизацию с контентом. For example, after you restore a content database, the BLOB cache will be out of sync with the content. Чтобы исправить ситуацию, необходимо очистить кэш. To correct that situation, you must flush the BLOB cache. Дополнительную информацию можно узнать в статье очистка кэша больших двоичных объектов в SharePoint Server. For more information, see Flush the BLOB cache in SharePoint Server.

Настройка параметров кэша BLOB Configure BLOB cache settings

По умолчанию дисковый кэш BLOB отключен, и для использования этого кэша его необходимо включить на интерфейсном веб-сервере. Чтобы настроить параметры дискового кэша для веб-приложения, используйте следующую процедуру. By default, the disk-based BLOB cache is off and must be enabled on the front-end web server if you want to use it. Use the following procedure to configure disk-based cache settings for a web application.

Перед внесением изменений в файл web.config создайте его копию под другим именем (например, web.config1), чтобы в случае ошибки можно было восстановить исходный файл. Before you make changes to the web.config file, make a copy of it by using a different name (for example, web.config1), so that if a mistake is made in the file, you can restore the original file.

Настройка параметров кэша больших двоичных объектов To configure BLOB cache settings

Проверьте наличие следующих административных учетных данных: для настройки параметров кэша BLOB вы должны быть членом группы «Администраторы» на локальном компьютере. Verify that you have the following administrative credentials: You must be a member of the Administrators group on the local computer to configure the BLOB cache settings.

Откройте диспетчер серверов и в меню Сервис выберите Диспетчер служб IIS. Open Server Manager, click Tools, and then click Internet Information Services (IIS) Manager.

В диспетчере служб IIS в области подключения разверните узел с именем сервера, который содержит веб-приложение, а затем разверните узел сайты , чтобы просмотреть созданные веб-приложение или приложения. In Internet Information Services (IIS) Manager, in the Connections pane, expand the server name that contains the web application, and then expand Sites to view the web application or applications that have been created.

Щелкните правой кнопкой имя веб-приложения, для которого требуется настроить дисковый кэш, а затем выберите пункт Просмотреть. Открывается проводник Windows с каталогами для выбранного веб-приложения. Right-click the name of the web application for which you want to configure the disk-based cache, and then click Explore. Windows Explorer opens, with the directories for the selected web application listed.

В диалоговом окне Открыть с помощью выберите Блокнот и нажмите кнопку ОК. In the Open With dialog box, click Notepad, and then click OK.

В открытом в Блокноте файле web.config найдите следующую строку: In the web.config Notepad file, find the following line:

По умолчанию максимальный размер изображения при использовании представлений изображений составляет 40 мегапикселей. The default max size for an image when using Image Renditions is 40 mega pixels. При необходимости это значение можно изменить, добавив параметр imageRenditionMaxSourcePixels. Should you want to modify this value you will need to add the imageRenditionMaxSourcePixels parameter. Пример: For example: При этом будет задан максимальный размер изображения для представлений изображений, которые будут работать при примерно 100 мегапиксели пикселях. This will set the max image size for Image Renditions to work at around 100 mega pixels.

В этой строке замените значение атрибута location на каталог, в котором достаточно места для размещения кэша. In this line, change the location attribute to specify a directory that has enough space to accommodate the cache size.

Мы настоятельно рекомендуем указать каталог, который находится не на том диске, где хранятся файлы подкачки серверной операционной системы или файлы журналов сервера. We strongly recommend that you specify a directory that is not on the same drive as where either the server operating system swap files or server log files are stored.

Чтобы добавить типы файлов в список кэширования или удалить их оттуда, измените регулярное выражение для атрибута path , включив или исключив в нем соответствующее расширение файлов. При добавлении расширений файлов обязательно отделяйте каждый тип файлов вертикальной чертой (|), как показано в этой строке кода. To add or remove file types from the list of file types to be cached, for the path attribute, modify the regular expression to include or remove the appropriate file extension. If you add file extensions, make sure to separate each file type with a pipe (|), as shown in this line of code.

Чтобы изменить размер кэша, введите новое значение для maxSize . To change the size of the cache, type a new number for maxSize . Этот размер задается в гигабайтах (ГБ) и по умолчанию равен 10 ГБ. The size is expressed in gigabytes (GB), and 10 GB is the default.

Не рекомендуется задавать размер кэша менее 10 ГБ. При установке размера кэша обязательно укажите достаточно большое число для того, чтобы предусмотреть резерв не менее 20 процентов от предполагаемого размера контента, который будет храниться в этом кэше. It is recommended that you not set the cache size smaller than 10 GB. When you set the cache size, make sure to specify a number large enough to provide a buffer at least 20 percent bigger than the estimated size of the content that will be stored in the cache.

Чтобы включить кэш больших двоичных объектов, enabled измените значение атрибута «false» с «true» на. To enable the BLOB cache, change the enabled attribute, from «false» to «true» .

Сохраните файл Блокнота и закройте его. Save the Notepad file, and then close it.

При сохранении изменения в файле web.config веб-приложение в Службы IIS 7.0 автоматически выполняет перезапуск. Такой перезапуск может привести к кратковременному перебою в обслуживании сайтов в этом веб-приложении, а пользователи могут потерять состояние сеанса. Сведения о перезапуске веб-приложений в IIS 7.0 см. в статье Перезапуск процесса IIS. When you save a change to the web.config file, the web application in Internet Information Services (IIS) 7.0 automatically recycles. This recycling can cause a brief interruption in service to sites contained in that web application, and users can lose session state. For information about recycling web applications in IIS 7.0, see IIS Process Recycling.

Настройка параметров профилей кэша Configure cache profile settings

Параметры профилей кэша может настроить администратор семейства сайтов в пользовательском интерфейсе на уровне семейства сайтов или администратор на уровне веб-приложения на интерфейсном веб-сервере. Следует включить кэш вывода страниц на уровне семейства сайтов, прежде чем можно будет настроить профили кэша вывода страниц на уровне семейства сайтов или уровне веб-приложения. Если профили кэша вывода страниц включены на уровне веб-приложения, указанные в файле Web.config параметры применяются ко всем профилям кэша вывода страниц, переопределяя любые значения, которые были введены через пользовательский интерфейс на уровне семейства сайтов. Cache profile settings can be configured in the user interface at the site collection level by a site collection administrator, as well as at the web application level by an administrator on the front-end web server. The page output cache must be enabled at the site collection level before page output cache profiles can be configured at either the site collection level or web application level. If page output cache profiles are enabled at the web application level, the settings specified in Web.config will be used for all page output cache profiles, overriding any values that have been entered through the user interface at the site collection level.

Чтобы использовать кэш вывода страниц и соответствующие параметры профилей кэша, на сайте следует использовать компонент публикации. To use the page output cache and the associated cache profile settings, you must be using the Publishing feature on your site.

Существует известная проблема, связанная с веб-частью «Поиск контента». Параметр SendContentBeforeQuery в веб-части не работает должным образом на страницах, на которых используется кэширование выводимых данных. Эту проблему устраняет накопительный пакет обновления для SharePoint Server 2013 за март 2013 г. Дополнительные сведения см. в статье 2767999 базы знаний Майкрософт Описание обновления для SharePoint Server 2013 за 12 марта 2013 г. There is a known issue with the Content Search Web Part. The SendContentBeforeQuery setting in the Web Part does not work correctly on pages that use output caching. This issue is resolved in the SharePoint Server 2013 cumulative update for March 2013. For more information, see Microsoft Knowledge Base article 2767999: Description of the SharePoint Server 2013 update: March 12, 2013.

Чтобы настроить параметры профилей кэша для веб-приложения, используйте следующую процедуру. Use the following procedure to configure the cache profile settings for a web application.

Настройка параметров профиля кэша вывода страниц To configure page output cache profile settings

Проверьте наличие следующих административных учетных данных: для настройки параметров профилей кэша вы должны быть членом группы «Администраторы» на локальном компьютере. Verify that you have the following administrative credentials: You must be a member of the Administrators group on the local computer to configure the cache profile settings.

Щелкните правой кнопкой мыши файл Web. config, выберите Открыть и выберите Блокнот , если вам будет предложено найти программу, которая будет использоваться для открытия этого файла. Right-click web.config, click Open and choose Notepad if you’re asked to find a program to use to open this file.

В открытом в Блокноте файле web.config найдите следующую строку: In the web.config Notepad file, find the following line:

Чтобы включить профиль кэша на уровне веб-приложения, измените значение useCacheProfileOverrides атрибута с «false» на. «true» To enable the cache profile at the web application level, change the useCacheProfileOverrides attribute, from «false» to «true» .

Если установить значение true, указанные в файле Web.config параметры применяются ко всем профилям кэша вывода страниц, переопределяя любые значения, которые были введены через пользовательский интерфейс на уровне семейства сайтов. If you set this to true the settings specified in Web.config will be used for all page output cache profiles. This overrides any values that have been entered through the user interface at the site collection level.

Чтобы переопределить varyByHeader атрибут, введите настраиваемый параметр, указанный в свойстве HttpCachePolicy. VaryByHeadersдля записи библиотеки классов .NET Framework. To override the varyByHeader attribute, type a custom parameter as specified in the .NET Framework Class Library entry HttpCachePolicy.VaryByHeaders Property.

Чтобы переопределить varyByParam атрибут, введите настраиваемый параметр, указанный в свойстве HttpCachePolicy. VaryByParamsдля записи библиотеки классов .NET Framework. To override the varyByParam attribute, type a custom parameter as specified in the .NET Framework Class Library entry HttpCachePolicy.VaryByParams Property.

Чтобы переопределить varyByCustom атрибут, введите настраиваемый параметр, указанный в методе HttpCachePolicy. SetVaryByCustomдля записи библиотеки классов .NET Framework. To override the varyByCustom attribute, type a custom parameter as specified in the .NET Framework Class Library entry HttpCachePolicy.SetVaryByCustom Method.

Чтобы переопределить varyByRights атрибут, замените значение «true» на. «false» To override the varyByRights attribute, change the value from «true» to «false» . Это устранит требование о том, что пользователи должны иметь идентичные действительные разрешения на всех защищаемых объектах, чтобы просматривать одну и ту же кэшированную страницу в качестве любого другого пользователя. This will remove the requirement that users must have identical effective permissions on all securable objects to see the same cached page as any other user.

Чтобы переопределить cacheForEditRights атрибут, измените атрибут » cacheForEditRights с» «false» на. «true» To override the cacheForEditRights attribute, change the cacheForEditRights attribute, from «false» to «true» . При этом будет выполнен обход нормального режима работы, при котором страницы людей с разрешениями на правку кэшируются. This will bypass the normal behavior in which people with edit permissions have their pages cached.

Сохраните файл Блокнота и закройте его. Save the Notepad file, and then close it.

При сохранении изменения в файле Web. config веб-приложение в службах IIS 7,0 автоматически перезапускается. When you save a change to the web.config file, the web application in Internet Information Services (IIS) 7.0 automatically recycles. Такой перезапуск может привести к кратковременному перебою в обслуживании сайтов в этом веб-приложении, а пользователи могут потерять состояние сеанса. This recycling can cause a brief interruption in service to sites contained in that web application, and users can lose session state. Сведения о перезапуске веб-приложений в IIS 7,0 можно найти в разделе Запуск или остановка веб-сервера (IIS 8). For information about recycling web applications in IIS 7.0, see Start or Stop the Web Server (IIS 8).

Настройка параметров кэша объектов Configure object cache settings

Администратор семейства сайтов может настроить параметры кэша объектов в пользовательском интерфейсе на уровне семейства сайтов, по умолчанию этот кэш включен. Максимальный размер кэша можно настроить на уровне веб-приложения на интерфейсном веб-сервере, чтобы установить ограничение на максимальный объем памяти, занимаемый кэшем для всех семейств сайтов. Например, отдельные семейства сайтов могут иметь кэш объектов, равный 100 МБ, а для веб-приложения может быть установлено значение 1 ГБ. В этом случае все кэши на сервере вместе не могут использовать более 1 ГБ памяти. The object cache settings can be configured at the site collection level in the user interface by a site collection administrator, and is on by default. The maximum cache size can be configured at the web application level on the front-end web server to place a restriction on the maximum amount of memory that the cache will use for all site collections. For example, individual site collections might have the object cache set at 100 MB, while the web application might be set at 1 GB. In this case, no more than 1 GB of memory will be used by all the caches on the server.

Чтобы использовать кэш объектов, на сайте следует использовать компонент публикации. To use the object cache, you must be using the Publishing feature on your site.

Чтобы настроить параметры кэша объектов для веб-приложения на интерфейсном веб-сервере, используйте следующую процедуру. Use the following procedure to configure the object cache settings for a web application on a front-end web server.

Настройка параметров кэша объектов To configure object cache settings

Проверьте наличие следующих административных учетных данных: для настройки параметров кэша объектов вы должны быть членом группы «Администраторы» на локальном компьютере. Verify that you have the following administrative credentials: You must be a member of the Administrators group on the local computer to configure the object cache settings.

Щелкните правой кнопкой мыши файл Web. config, выберите Открыть и выберите Блокнот , если вам будет предложено найти программу, которая будет использоваться для открытия этого файла. Right-click web.config, click Open and select Notepad if you’re asked to find a program to use to open this file.

В открытом в Блокноте файле web.config найдите следующую строку: In the Web.config Notepad file, find the following line:

Чтобы изменить размер кэша, введите новое значение для maxSize . Этот размер задается в мегабайтах (МБ) и по умолчанию равен 100 МБ. To change the size of the cache, type a new number for maxSize . The size is expressed in megabytes (MB), and 100 MB is the default.

Сохраните файл Блокнота и закройте его. Save the Notepad file, and then close it.

Кэширование в ASP.NET MVC

Атрибут OutputCache

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

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

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

Действие атрибута OutputCache можно настроить с помощью его свойств:

CacheProfle : определяет конфигурацию кэширования

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

Location : место, где размещается кэшированный контент

NoStore : если данное значение равно true , в ответе в заголовке Cache-Control устанавливается флаг no-store , что указывает браузеру, что контент не надо сохранять

SqlDependency : определяет зависимость между кэшем и таблицой в бд

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

VaryByHeader : указывает на набор заголовков, по которым будут определяться различные версии кэшированных данных

VaryByParam : указывает на параметры строки запроса или параметры переданных форм, по которым будут определяться различные версии кэшированных данных

С помощью свойства Location можно определить в качестве хранилища кэшированного контента как сервер, так и браузер клиента. В частности, данное свойство может принимать одно из значений перечисления System.Web.UI.OutputCacheLocation :

Any : контент кэшируется как на клиенте, так и на прокси-сервере и в выходном кэше сервера

Client : контент кэшируется на клиенте

Downstream : контент кэшируется как на клиенте, так и на прокси-сервере. Выходной кэш сервера не используется

None : для заголовка Cache-Control устанавливается значение no-cache , что значит, что контент не будет нигде кэшироваться

Server : контент кэшируется только в выходном кэше сервера

ServerAndClient : контент кэшируется на клиенте и в выходном кэше сервера

Рассмотрим на примере:

Для простоты примера в данном случае выводится в браузере значение статической переменной. При обычной работе без кэширования при каждом обращении к данному методу значение этой переменной увеличивалось бы на единицу. Но здесь используется атрибут OutputCache , который задает, во-первых, время кэширования — 30 секунд, во-вторых, место кэша — клиент и возвожные прокси-серверы, через которые может идти запрос.

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

Мы можем проинспектировать заголовки ответа в браузере (например, в IE):

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

Подобным образом мы можем ограничиться кэшированием на сервере:

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

При повторных обращениях опять же время довольно мало — в данном случае всего 15 миллисекунд.

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

HTTP протокол: основные правила Интернета, которые должен знать каждый веб-разработчик. Как браузер взаимодействует с сервером.

Тема 13: Кэширование в HTTP: механизмы клиентского и серверного кэша в HTTP

Привет, читатель блога ZametkiNaPolyah.ru! Продолжим знакомиться с протоколом HTTP в рубрике Серверы и протоколы и ее разделе HTTP протокол. Эта запись будет о кэширование в HTTP протоколе. Мы с тобой поговорим о том для чего вообще нужно кэширование в HTTP, о правилах кэширования, о том, какие могут быть ошибки при кэшировании, а так же о том какие есть механизмы о клиента и сервера для управления процессом кэширования в HTTP и о различных моделях при кэширование.

Кэширование в HTTP

Для чего нужно кэширование в HTTP протоколе

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

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

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

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

Правильность кэширования в HTTP

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

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

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

Предупреждения при кэшировании в HTTP

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

Механизмы управления кэшированием в HTTP. Поле заголовка Cache-Control в HTTP

В версии протокола HTTP 1.1 в качестве механизмов управления кэшированием используется поле заголовка Cache-Control. Заголовок Cache-Control позволяет управлять HTTP кэшем, как клиенту, так и HTTP серверу при помощи директив, которые они передают вместе с ответами и запросами. При этом директивы, передаваемые в поле заголовка Cache-Control, отменяют значения по умолчанию для кэширования в HTTP. Необходимо отметить тот момент, что директивам заголовка Cache-Control должны повиноваться все участники цепочки обмена данными между конечным сервером и клиентом.

Для управления кэшированием HTTP клиенты могут использовать директивы, которые указаны в таблице ниже. Директивы поля заголовка Cache-Control для клиента

Номер	Директивы поля заголовка Cache— Control для клиента и их описание
1	Директива поля заголовка Cache— Control для клиентского запроса: no— cache Директива no-cache говорит серверу о том, что для последующего запроса ответ не должен отправляться из кэша без проверки с содержимым исходного сервера.
2	Директива поля заголовка Cache— Control для клиентского запроса: no— store Директива no-store говорит серверу о том, что ни запрос клиента, ни ответ сервера не должны кэшироваться. Это сделано для безопасности.
3	Директива поля заголовка Cache— Control для клиентского запроса: max— age = seconds Директива max-age говорит серверу о том, что кэш должен быть не старше времени, которое указано в секундах.
4	Директива поля заголовка Cache— Control для клиентского запроса: max— stale [ = seconds ] Директива max-stale говорит серверу о том, что клиент примет кэшированный HTTP ответ в том случае, если его возраст не превышает времени, указанного в секундах.
5	Директива поля заголовка Cache— Control для клиентского запроса: min— fresh = seconds Директива min-fresh говорит серверу о том, что клиент примет кэшированный HTTP ответ в том случае, если время жизни кэша не больше указанных секунд.
6	Директива поля заголовка Cache— Control для клиентского запроса: no— transform Директива min-fresh говорит серверу о том, что к запрашиваемому ресурсу не должно применяться никаких преобразований.
7	Директива поля заголовка Cache— Control для клиентского запроса: only— if— cached Директива min-fresh говорит серверу о том, что клиент примет только кэшированный HTTP ответ, если подходящего ответа нет в кэше сервера, то делать ничего не надо.

Мы рассмотрели механизм управления кэшированием HTTP клиентом, теперь давайте разберемся с механизмами управления кэшированием со стороны HTTP сервера. Другими словами: как HTTP ответы могут управлять кэшированием. Управление кэширование со стороны сервера происходит аналогичным образом – при помощи заголовка Cache-Control, но директивы заголовка Cache-Control у сервера свои и, соответственно, свои механизмы управления кэшированием при HTTP соединение. Давайте сведем серверные директивы заголовка Cache-Control в одну таблицу.

Номер	Директивы поля заголовка Cache— Control для сервера и их описание
1	Директива поля заголовка Cache— Control ответа сервера: public Директива ответа сервера Public говорит о том, что ответ сервера можно сохранять в любом кэше.
2	Директива поля заголовка Cache— Control ответа сервера: private Директива ответа сервера private говорит о том, что ответ сервера нужно сохранять в закрытом кэше, который предназначен только для этого пользователя.
3	Директива поля заголовка Cache— Control ответа сервера: no— cache Директива ответа сервера no— cache говорит о том, что кэшированный ответ не должен отправляться клиенту без его предварительной проверки.
4	Директива поля заголовка Cache— Control ответа сервера: no— store Директива ответа сервера no— store говорит о том, что ответ сервера нельзя сохранять в кэше.
5	Директива поля заголовка Cache— Control ответа сервера: no— transform Директива ответа сервера no— transform говорит о том, что к ответу сервера не должно применяться никаких преобразований ни одним из узлов цепочки.
6	Директива поля заголовка Cache— Control ответа сервера: must— revalidate Директива ответа сервера must— revalidate говорит о том, что если HTTP сообщение сервера устарело, то к нему должна применяться предварительная проверка.
7	Директива поля заголовка Cache— Control ответа сервера: proxy— revalidate Директива ответа сервера proxy— revalidate говорит о том, что и предыдущая директива, но только для промежуточных серверов.
8	Директива поля заголовка Cache— Control ответа сервера: max— age = seconds Директива ответа сервера max— age говорит о том, сколько живет кэш на сервере.
9	Директива поля заголовка Cache— Control ответа сервера: s— maxage = seconds Директива ответа сервера s— maxage говорит о том, что и директива max-age, но для CDN-серверов

Общий синтаксис механизмов кэширования в HTTP вы сможете найти ниже.

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 накладываются некоторые ограничения. Чтобы правильно поддерживать уведомления, команда должна отвечать следующим требованиям.