Лучшее решение для кэширования
Я сделал все, что нужно, чтобы добавить пакет в сеть MVC 3 (я новичок в существующем решении). Styles.Render не работал для меня. Я наконец обнаружил, что просто пропустил двоеточие. На главной странице: <%: Styles.Render("~/Content/Css") %> Я все еще не понимаю, почему (на той же странице) <% Html.RenderPartial("LogOnUserControl"); %> работает без двоеточия.
9 ответов
Кэш - важная часть веб-приложения, но не существует волшебного решения, подходящего для каждого проекта. Работа над оптимизацией до того, как ваше приложение заработает, обычно - плохая идея. Прежде чем задаться вопросом, где следует реализовать уровень кеширования, первым делом необходимо убедиться, что ваше приложение работает хорошо (даже если медленно) без какой-либо оптимизации кеша.
Когда этот первый шаг будет достигнут, вы можете начать профилирование приложения, перечисление функций, которые, похоже, используют много ресурсов (может быть ЦП, память, ввод-вывод, доступ к базе данных) или требуют много времени для завершения (обычно из-за тех же симптомов).
Как только у вас есть список функций, которые, по вашему мнению, можно оптимизировать с помощью системы кэширования, есть два вопроса, которые вы должны задать себе:
«Как я могу улучшить все эти функции одновременно» (фокус макроса): очевидным ответом на этот вопрос часто является кеш доступа к данным. Обычно вы не хотите отправлять один и тот же запрос на сервер базы данных снова и снова, если данные, которые вы получаете взамен, всегда одинаковы. Так что хранение этого типа данных в кеше с разумным сроком службы всегда будет хорошей идеей.
«Как я могу улучшить каждую функцию» (микро-фокус): это сложно, и вам нужно очень хорошо понять свое приложение, чтобы понять это. Некоторые данные можно кэшировать, некоторые - нет, некоторые - нет. Отладчик и профилировщик обычно являются отличными инструментами для этого шага, потому что они помогают вам понять, почему функция работает медленно, и дают вам подсказки о том, как их следует оптимизировать.
Оптимизация, которую вы собираетесь выяснить, может быть связанные с любым уровнем вашего приложения (презентация, бизнес-логика, данные), но это не значит, что вы должны реализовать их все. Вы должны принять во внимание несколько важных моментов:
- Действительно ли нужно оптимизировать эту функцию? (Является ли это заметным преимуществом для клиента? Для оборудования? Для всего приложения? Для других приложений?)
- Какого увеличения производительности я могу добиться? (1%, 200%, ...)
- Сколько времени у меня уйдет на его оптимизацию? (1 час, 12 дней, ...)
- Насколько рискованно его оптимизировать? (может ли это сломать приложение? Для клиента?)
Когда у вас есть ответы на эти вопросы, самое время поговорить об этом с вашим руководителем проекта, с вашими коллегами или даже с людьми, которые не работают в приложении с вами. Хорошо иметь нейтральное мнение, равно как и мнение нетехнического (или менее технического).
Кэширование - это оптимизация производительности, поэтому делайте это там, где есть узкое место. Вы узнаете, где находится узкое место, измерив его трижды, а затем еще раз.
Остерегайтесь непостоянной согласованности ваших данных при кэшировании, например, вы не хотите кэшировать все свое приложение для торговли акциями.
Уровень данных - всем слоям выше этого уровня не нужно знать, откуда берутся данные. Я бы также кэшировал только те данные, которые не очень изменчивы, или включил бы некоторую политику истечения срока действия.
Мы реализуем его на уровне бизнес-логики между взаимодействиями с уровнем представления. Если поступает запрос от уровня представления и он кэшируется, мы можем пропустить большую часть логики и доступа к данным.
Я настоятельно рекомендую MemCached вместо MS Velocity, настройка Velocity была сложной задачей!
Data layer. But it is confusing because we use ASP.NET caching. With its expiration and dependency capability, it's pretty handy. So our business layer has no idea the data layer might be caching but the data layer uses a presentation-layer technology for caching! :(
Кэш: реализован на уровне доступа к данным, доступен на уровне бизнес-логики.
это означает, что вы должны внимательно следить за кеш устареет.
Вы можете эмулировать движения / щелчки мыши и ввод с клавиатуры в Java с помощью класса Robot . Он также позволяет делать снимки экрана.
- Есть ли идентификатор в вашем кэше ( Словарь идентификатора / объекта)?
- Нет
- Захватите объект из базы данных
- AquireWriterLock из ReaderWriterLock (почему ReaderWriter? Потому что вы не часто пишете, но часто читаете)
- Добавить объект в кеш
- Да
- Получить объект из словаря
Это мое предпочтительное решение, при необходимости вы можете добавить таймауты, очистку и т. д. Или используйте memcached или блок кэширования корпоративной библиотеки Microsoft , но их обычно бывает слишком много.
Я не могу говорить о конкретных вещах ASP.NET, но я обычно обнаружил, что вы можете кэшировать на каждом уровне. Ваш уровень данных будет кэшировать ответы данных, вашему уровню представления может потребоваться кэширование сгенерированных элементов представления (например, пользовательских таблиц стилей) и т. Д. В большинстве случаев уровень данных является самым тяжелым пользователем кеша, а другие уровни будут включать объектный кеш, если доказана его необходимость.
Самая сложная часть - добиться правильной работы функции инвалидации кеша. Устаревшие кеши - серьезная головная боль при развертывании. Обязательно выясните, как вы собираетесь управлять временем жизни каждого объекта кеша. Кеши LRU хорошо подходят для кэширования статических элементов по запросу. Однако для большинства кешей данных потребуется явный жизненный цикл, будь он основан на таймере истечения срока действия или привязан к какой-либо пользовательской сессии.
You should consider caching at EVERY layer.
The best place to cache is as near to the client request as possible (so you do as little work as possible to serve the response). In web apps, yes at the presentation layer, at the business layer and the data layer.
(Side note: If you are basically peppering your business logic code with caching logic here and there, you should really look into seperation of concerns to avoid your code becoming a big ball of mud :-) )