Как Вы фиксируете запросы, которые только отстают, пока они не кэшируются
Вы можете попробовать что-то вроде этого:
- Вы можете создать функцию, которая работает с этим представлением пользовательского интерфейса.
- В этой функции вы можете вызвать
buildStuffи вернуть ей 3тега. - Затем в основном рендере вы можете проверить свое состояние и сделать рендеринг соответственно. Это сделает ваш рендер чистым и декларативным.
getBuildJSX() {
const stuff = this.buildStuff();
return Array.from({ length: 3}, () => { stuff }
);
}
render() {
const statement = true
return (
{
statement ? this.getBuilsJSX() : null
}
);
}
6 ответов
Согласно http://morten.lyhr.dk/2007/10/how-to-clear-sql-server-query-cache.html, можно выполнить следующее для очистки кэша:
DBCC DROPCLEANBUFFERS
DBCC FREEPROCCACHE
Править: Я сверился с документацией SQL Server, которую я имею, и это, по крайней мере, верно для SQL Server 2000.
Позвольте мне предложить, чтобы Вы осмотрели план выполнения относительно запросов, которые ответственны за Ваши проблемы низкой производительности.
Необходимо определить, в рамках плана выполнения, какие шаги имеют самую высокую стоимость и почему. Могло случиться так, что Ваши запросы выполняют сканирование таблицы, или что несоответствующий индекс используется, например.
Существует очень подробная, бесплатная электронная книга, доступная с веб-сайта RedGate, который концентрируется конкретно на понимании содержания планов выполнения.
https://www.red-gate.com/Dynamic/Downloads/DownloadForm.aspx? download=ebook1
Можно найти, что существует конкретный план выполнения, что требуется использоваться для запроса. Можно вызвать, какой план выполнения используется для запроса в SQL Server с помощью подсказок запроса. Это - вполне усовершенствованное понятие однако и должно использоваться с усмотрением. Дополнительную информацию см. в следующей Microsoft White Paper.
http://www.microsoft.com/technet/prodtechnol/sql/2005/frcqupln.mspx
Я также не рекомендовал бы очистить кэш процедур на продуктивной среде, поскольку это будет вредно для производительности всех других запросов на платформе, которые в настоящее время не являются проблемами производительности опыта.
При выполнении хранимой процедуры, например, можно удостовериться, что новый план выполнения вычисляется для каждого осуществления процедуры при помощи команды WITH RECOMPILE.
Для получения информации о настройке общей производительности существуют некоторые превосходные ресурсы, законченные в блоге Brent Ozar.
http://www.brentozar.com/sql-server-performance-tuning/
Надеюсь, это поможет. Удачи.
Использование может использовать
DBCC DROPCLEANBUFFERS
DBCC FREEPROCCACHE
Но только используйте это в своей среде разработки при настройке запросов для развертывания на живом сервере.
Я думаю, что люди убегают в неправильном направлении. Если я понимаю, Вы хотите, чтобы производительность была хороша все время? Разве они не выполняют быстро 2-е (и последующее выполнение) и являются медленными в первый раз?
Команды DBCC выше убирают кэш, вызывая ХУДШУЮ производительность.
То, что Вы хотите, я думаю, является к началу насосом, и кэшируйте данные. Можно сделать это с некоторыми процедурами запуска, которые выполняют запросы и данные загрузки в память.
Память является конечным ресурсом, таким образом, Вы не можете загрузить все данные, вероятно, в память, но можно найти баланс. Брент имеет некоторые хорошие ссылки выше, чтобы помочь изучить то, что можно сделать здесь.
Из MSDN:
"Используйте DBCC DROPCLEANBUFFERS для тестирования запросов с холодным кэш-буфером, не закрываясь и перезапуская сервер".
Оптимизация запросов является большим предметом, нет никакого единственного ответа на Ваш вопрос. Подсказки относительно того, что сделать, являются всеми в плане запросов, который должен быть тем же независимо от того, кэшируются ли результаты или нет.
Ищите обычные вещи, такие как сканирования таблицы, индексы, не используясь, когда Вы будете ожидать, что они будут использоваться и т.д. и т.д. В конечном счете Вы можете иметь к revew свою модель данных и возможно реализовать стратегию денормализации.