Лучшее решение для кеширования

Question

Где лучше всего реализовать кэширование в веб-приложении?

• На уровне презентации (надеюсь, что нет)?
• На уровне бизнес-логики?
• На уровне данных?

Я собираюсь использовать что-то вроде memcached или MS Velocity под капотом.

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

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

Answer 1

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

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

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

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

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

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

• Нужно ли оптимизировать эту функцию?(это заметный выигрыш для клиента? Для оборудования? Для всего приложения? Для других приложений?)
• Какого увеличения производительности я могу достичь?(1%, 200%, ...)
• Сколько времени мне потребуется, чтобы оптимизировать его?(1 час, 12 дней, ...)
• Насколько рискованно его оптимизировать?(может ли это что-то сломать для приложения? Для клиента?)

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

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

Answer 2

Вы должны рассмотреть кэширование на КАЖДОМ слое.

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

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

Answer 3

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

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

Answer 4

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

Answer 5

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

Я бы настоятельно рекомендовал MemCached поверх MS Velocity, настройка скорости была трудной задачей!

Answer 6

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

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

Answer 7

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

Простая настройка (для одного бизнес-объекта):

1. MyCache - статический класс
2. Один статический метод: MyCache.Retrieve (id), возвращает объект
3. Класс использует статический словарь для хранения и статический ReaderWriterLock

Затем метод Retrieve выполняет следующее:

1. Идентификатор в вашем кэше ( словарь идентификатора / объекта)?
2. Нет
   • Получить объект из базы данных
   • AquireWriterLock из ReaderWriterLock (почему ReaderWriter? Потому что вы пишете не часто, а часто)
   • Добавить объект в кеш
3. Да
   • Получить объект из словаря

Это мое предпочтительное решение, вы можете добавить таймауты, очистку и так далее, если вам нужно. Или используйте memcached или Блок кэширования Microsoft Enterprise Library , но обычно они излишни.

Answer 8

Уровень данных. Но это сбивает с толку, потому что мы используем кэширование ASP.NET. С возможностью истечения срока действия и зависимостями это очень удобно. Таким образом, наш бизнес-уровень понятия не имеет, что уровень данных может кэшироваться, но уровень данных использует технологию уровня представления для кэширования! (

Answer 9

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

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