iscrafm, вся архитектурная нить, о которой я спрашивал Вас, находится ниже. Руководствуясь данным манускриптом (из того же Application Architecture Guide), нужно выбрать свою стратегию кеширования:
Этапы проектирования стратегии кэшированияКэширование может играть решающую роль в повышении производительности. Исключительно важно спроектировать соответствующую стратегию кэширования, потому что неправильный выбор методик может негативно сказаться на производительности. Рассматриваемые далее этапы проектирования помогут выработать правильную стратегию кэширования для приложения.
Шаг 1 – Выбор данных, подлежащих кэшированию
В ходе проектирования приложения важно определиться с тем, какие данные годятся для кэширования. Для каждого слоя приложения создайте список данных, которые могут быть кэшированы. Рассмотрите возможность кэширования следующих типов данных:
Общие данные приложения. Рассмотрите возможность кэширования статических данных, которые используются всеми пользователям приложения. Примерами таких данных являются списки продуктов и сведения о продуктах.
Относительно статические данные. Рассмотрите возможность кэширования полностью статических данных или данных, которые меняются нечасто, например, константы или фиксированные значения, считываемые из конфигурационного файла или базы данных.
Относительно статические Веб-страницы. Рассмотрите возможность кэширования вывода Веб-страниц или частей Веб-страниц, которые меняются нечасто.
Параметры хранимых процедур и результаты запросов. Рассмотрите возможность кэширования часто используемых параметров и результатов запросов.
Шаг 2 – Выбор места кэширования данных
При принятии решения о месте кэширования данных обычно необходимо рассмотреть два вопроса: физическое размещение кэша и его логическое размещение.
Физически кэш размещается либо в памяти, либо на диске в файлах или базе данных. Кэширование в памяти может осуществляться с помощью механизма кэширования ASP.NET, Enterprise Library Caching Application Block или механизма распределенного кэширования в памяти, такого как проект Microsoft под кодовым названием Velocity или технология Memcached от компании Danga Interactive .
Размещайте кэш в памяти, если приложение часто использует данные; если кэшированные данные относительно часто меняются, и их приходится довольно часто запрашивать повторно; и если объем кэшированных данных относительно мал. Размещайте кэш в системе или базе данных, если использовать данные из хранилища кэша более эффективно по сравнению с их запросом из исходного хранилища; если кэшированные данные относительно редко меняются; и если сервисы для повторного запроса данных не всегда доступны. Подход с хранением кэша на диске также идеален при большом объеме кэшированных данных, или если кэшированные данные должны сохраняться при перезапусках процесса или компьютера.
Логическое размещение кэша – это его место в логике приложения. Важно кэшировать данные в максимальной близости к месту их использования. Это обеспечит снижение объема необходимой обработки, сокращение количества обращений к сети и времени отклика приложения и повышение производительности.
Принимая решение о логическом размещении кэша данных, руководствуйтесь следующими рекомендациями:
Кэшируйте на клиенте данные, характерные для страницы или пользователя; данные, не содержащие конфиденциальных сведений; и данные небольшого объема.
Кэшируйте на прокси-сервере или Веб-сервере (для Веб-приложений) относительно статические страницы, часто запрашиваемые клиентами; страницы, обновляемые с известной периодичностью; или результаты, возвращаемые Веб-сервисами. Также используйте этот подход для страниц, которые могут формировать разный вывод в зависимости от параметров HTTP, и эти параметры меняются нечасто. Это особенно полезно при небольшом диапазоне выходных данных.
Кэшируйте в слое представления относительно статический вывод страниц; небольшие объемы данных, касающиеся предпочтений пользователей для небольших групп пользователей; или если имеются элементы UI, создание которых достаточно ресурсоемко. Также используйте этот подход для ресурсоемких данных, отображаемых пользователю, например, списков продуктов или сведений о продуктах
Кэшируйте данные в бизнес-слое, если необходимо сохранять состояние сервиса, бизнес-процесса или рабочего процесса; или если для обработки запросов от уровня представления требуются относительно статические данные, создание которых достаточно ресурсоемко.
Кэшируйте данные в слое доступа к данным при наличии коллекции входных параметров для часто вызываемых хранимых процедур или небольших объемов необработанных данных, возвращаемых часто выполняемыми запросами. Рассмотрите варианты кэширования для типизированных наборов данных в слое данных.
Кэшируйте в отдельную таблицу базы данных любые данные, для получения которых требуется выполнение достаточно сложного и ресурсоемкого запроса. Этот вариант кэширования поможет также обеспечить повышение производительности, если требуется кэшировать очень большие объемы данных при реализации механизма разделения на страницы.
Шаг 3 – Определение формата кэширования данных
Теперь, определившись с данными, которые необходимо кэшировать, и приняв решение о месторасположении кэша, важно выбрать формат для кэшированных данных. При кэшировании храните данные в формате, оптимизированном для предполагаемого использования и не требующем дополнительной или повторной обработки или преобразования.
Этого правила следует придерживаться, если данные кэшируются в памяти, если кэш не будет использоваться совместно разными процессами или компьютерами, если нет необходимости перемещать кэшированные данные в разные участки памяти, и если приходится кэшировать необработанные данные, такие как объекты DataSet, DataTable и Веб-страницы.
Если необходимо хранить или передавать кэшированные данные, рассмотрите возможность их сериализации. Сериализация кэшированных данных – хороший выбор для кэширования данных на диск или для хранения состояния сеансов на отдельном сервере или базе данных SQL Server. Это также хороший подход, если необходимо обеспечить совместное использование кэша разными процессами или компьютерами, перемещать кэшированные данные в разные участки памяти или кэшировать собственные объекты. Сериализация может осуществляться с помощью механизма сериализации XML или механизма бинарной сериализации.
Механизм сериализации XML подойдет, если определяющим фактором является возможность взаимодействия. Если основной упор делается на производительность, используйте механизм бинарной сериализации.
Шаг 4 – Выработка подходящей стратегии управления кэшем
Необходимо определить соответствующую политику срока действия кэша и сброса кэша. И удаление по истечении срока действия, и сброс данных являются стратегиями удаления кэшированных данных из хранилища кэша. Отличаются они тем, что при сбросе могут удаляться действительные данные для высвобождения памяти под более часто используемые элементы, тогда как удаление данных по истечении срока их действия означает, что эти данные стали недействительными. Проверьте возможности используемой базовой системы кэширования, не все реализации кэша предлагают все возможные варианты.
Стратегия срока действия кэша должна обеспечивать, чтобы в кэше находились только действительные данные и элементы.
Политика срока действия может использовать как срок действия по времени, так и срок действия по уведомлению:
При использовании политики срока действия по времени кэшированные данные устаревают или становятся недействительными по прошествии определенного интервала времени в абсолютных или относительных показателях. Такую политику рекомендуется применять для часто меняющихся данных, если кэшированные данные регулярно обновляются, или если кэшированные данные остаются действительными лишь в течение определенного промежутка времени или до определенного времени. Выбирая политику срока действия по времени, можно остановиться на политике срока действия по абсолютному времени или по скользящему временному интервалу. Политика срока действия по абсолютному времени позволяет определять время жизни кэшированных данных через задание времени истечения их срока действия. Политика срока действия по скользящему временному интервалу определяет время жизни кэшированных данных путем задания промежутка времени с момента последнего доступа к кэшированным данным, через который они будут считаться устаревшими.
При использовании политики срока действия по уведомлению кэшированные данные устаревают или становятся недействительными на основании уведомлений от внутренних или внешних источников. Такая политика подойдет при работе с нечасто меняющимися кэшированными данными, если кэшированные данные обновляются через непостоянные промежутки времени, или если данные остаются действительными до тех пор, пока не будут изменены внешними или внутренними системами. Обычно в качестве источников уведомлений выступают модули записи файлов на диск, события WMI, уведомления об изменениях в базе данных и операции бизнес-логики. Поступление уведомления означает истечение срока действия или устаревание всех соответствующих элементов кэша.
Стратегия сброса кэша должна обеспечивать эффективное использование хранилища, памяти и других ресурсов. Стратегия сброса кэша может быть явной или в результате сборки мусора:
Для явного сброса кэша необходимо задать, когда элемент должен быть удален. Такая политика используется, если требуется поддерживать сценарий удаления поврежденных или устаревших кэшированных данных, если используются хранилища, не поддерживающие сборки мусора, или при работе с кэшем на диске.
Для сборки мусора необходимо определить условия и набор эвристических правил, согласно которым элемент должен быть удален в ходе сборки мусора. Эту политику рекомендуется применять, если требуется автоматически активировать сборку мусора при устаревании ресурсов системы, если требуется обеспечить автоматическое удаление редко используемых или маловажных элементов из кэша, или при работе с кэшем в памяти.
Рассмотрим общие правила сборки мусора:
Алгоритм вытеснения по давности использования (Least Recently Used) обеспечивает удаление элементов, которые не использовались в течение наибольшего периода времени.
Алгоритм вытеснения по частоте использования (Least Frequently Used) обеспечивает удаление элементов, которые с момента загрузки использовались реже всего.
При использовании алгоритма вытеснения по приоритетности (Priority) всем кэшированным элементам присваиваются приоритеты, и сборка мусора выполняется на основании этих приоритетов с сохранением элементов, имеющих более высокий приоритет.
Шаг 5 – Выбор метода загрузки кэшированных данных
Правильный выбор способа наполнения кэша позволит увеличить производительность и сократить время отклика приложения. Принимая решение о том, как будет заполняться кэш, учитывайте, сколько данных должно быть доступно при запуске приложения или при исходной загрузке кэша, а также то, какое влияние это будет иметь на время запуска и производительность приложения. Например, можно выполнять предварительную загрузку данных в кэш при запуске приложения или извлекать кэшированные данные, только когда они запрашиваются. Загрузка данных в кэш при запуске приложения может сократить время отклика приложения, но при этом увеличить время загрузки.
С другой стороны, загрузка данных в кэш только по необходимости способствует сокращению времени запуска приложения, но может увеличить время отклика при первом обращении к этим данным.
При проектировании стратегии заполнения кэша может использоваться упреждающая или реактивная загрузка:
Упреждающая загрузка обеспечивает извлечение всех данных приложения при его запуске и их кэширование на весь период выполнения приложения. Упреждающая загрузка подойдет для относительно статических данных, или если известны заранее частота их обновления, время жизни и размер. Если размер данных неизвестен, их загрузка может привести к истощению ресурсов системы. Используйте этот вариант загрузки также, если в качестве источника кэшированных данных предполагается медленная база данных, или данные извлекаются по медленной сети или из ненадежного Веб-сервиса.
Реактивная загрузка обеспечивает извлечение данных при запросе приложением и их кэширование для запросов в будущем. Реактивная загрузка подойдет для относительно непостоянных данных, когда время жизни кэшированных данных неизвестно, объем кэшированных данных велик и источник данных надежен и всегда доступен.
