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

Question

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

Answer 1

Пока не реализовывать кеширование.

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

И, конечно, если у вас настроен сервер, когда вы наконец включите кэширование, он будет работать намного лучше намного дольше, чем если бы вы сделали это сегодня.

Answer 2

Некоторые правила большого пальца

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

Некоторые хитрости

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

Answer 3

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

• Параметры приложения (список стран, телефонные коды и т. Д.)
• Любые другие приложения, энергонезависимые данные (список ролей, даже если они настраиваются)
• Бизнес-данные, которые часто читаются и не сильно меняются (или не имеют большого значения, если они не точны на 100%)

Что не следует кэшировать:

• Изменчивые данные, которые часто изменяются (обычно бизнес-данные)

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

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

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

Надеюсь, это поможет вам.

Answer 4

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

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

Однажды я написал специальный код для кэширования данных для приложения, которое взаимодействовало с очень медленной базой данных учета, а затем оно было доступно только для чтения для данных, которые менялись не очень часто. Все записи отправлялись в БД. С SQL Server я никогда не сталкивался с ситуацией, когда встроенный интерфейс ASP.NET-to-SQL Server был медленной частью уравнения.

Answer 5

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

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

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

• GET client
• GET клиентские кавычки
• GET клиент цитата

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

• [Cache] клиент
• [Cache] клиентские кавычки
• [Cache] клиентская цитата
• GET клиент цитаты обновления