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

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

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

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

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

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

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

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

Шаг 3 – Определение формата кэширования данных

Теперь, определившись с данными, которые необходимо кэшировать, и приняв решение о месторасположении кэша, важно выбрать формат для кэшированных данных. При

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

Если необходимо хранить или передавать кэшированные данные, рассмотрите возможность их сериализации. Сериализация кэшированных данных – хороший выбор для кэширования данных на диск или для хранения состояния сеансов на отдельном сервере или базе данных SQL Server. Это также хороший подход, если необходимо обеспечить совместное использование кэша разными процессами или компьютерами, перемещать кэшированные данные в разные участки памяти или кэшировать собственные объекты. Сериализация может осуществляться с помощью механизма сериализации XML или механизма бинарной сериализации. Механизм сериализации XML подойдет, если определяющим фактором является возможность взаимодействия. Если основной упор делается на производительность, используйте механизм бинарной сериализации.

Шаг 4 – Выработка подходящей стратегии управления кэшем

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

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

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

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

Стратегия сброса кэша должна обеспечивать эффективное использование хранилища, памяти

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

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

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

Рассмотрим общие правила сборки мусора:

Алгоритм вытеснения по давности использования (Least Recently Used)

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

Алгоритм вытеснения по частоте использования (Least Frequently Used)

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

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

Шаг 5 – Выбор метода загрузки кэшированных данных

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