Lors de la comparaison du temps d'exécution de deux requêtes différentes, il est important d'effacer le cache pour s'assurer que l'exécution de la première requête ne modifie pas les performances de la seconde.
Dans une recherche Google, je pourrais trouver ces commandes:
DBCC FREESYSTEMCACHE
DBCC FREESESSIONCACHE
DBCC FREEPROCCACHE
En fait, mes requêtes prennent un temps plus réaliste à traiter après plusieurs exécutions qu'auparavant. Cependant, je ne suis pas sûr que ce soit la technique recommandée.
Quelle est la meilleure pratique?
sql-server
performance-testing
Andrerpena
la source
la source
DBCC FLUSHPROCINDB: Un nombre incorrect de paramètres a été attribué à l'instruction DBCC.DECLARE @myDb AS INT = DB_ID(); DBCC FLUSHPROCINDB(@myDb); GOpartir d'ici: stackoverflow.com/questions/7962789/…Réponse tardive mais peut être utile à d'autres lecteurs
DBCC DROPCLEANBUFFERS est une commande souvent utilisée pour tester et évaluer la vitesse d'exécution d'une requête. Cette commande (lorsqu'elle est exécutée) ne laisse que les pages endommagées, qui représentent en réalité une petite partie des données. Il supprime toutes les pages propres pour un serveur entier.
Sachez que cette commande ne doit pas être exécutée sur un environnement de production. L'exécution de cette commande aura pour résultat un cache de mémoire tampon essentiellement vide. L'exécution de toute requête après l'exécution de la commande DBCC DROPCLEANBUFFERS utilisera des lectures physiques pour ramener les données dans le cache, ce qui risque fort d'être beaucoup plus lent que la mémoire.
Là encore, traitez cette commande de la même manière que DBCC FREEPROCCACHE. Elle ne doit être exécutée sur aucun serveur de production, à moins que vous ne sachiez absolument ce que vous faites.
Cela peut être un outil de développement utile car vous pouvez exécuter une requête dans un environnement de test de performances à plusieurs reprises sans modification de la vitesse / de l'efficacité en raison de la mise en cache des données en mémoire.
En savoir plus sur: http://www.sqlshack.com/insight-into-the-sql-server-buffer-cache/
la source
On m'a toujours dit d'utiliser:
De MSDN :
la source
DBCC FREEPROCCACHEpour effacer tous les plans d'exécution en cache ...Les autres réponses sont correctes sur les raisons de ne pas courir
DBCC FREEPROCCACHE. Cependant, il y a aussi deux raisons de le faire:Si vous souhaitez comparer deux requêtes ou procédures différentes qui tentent de faire la même chose de différentes manières, elles risquent de s'afficher sur les mêmes pages. Si vous exécutez naïvement la requête n ° 1 puis la requête n ° 2, la seconde peut être beaucoup plus rapide simplement parce que ces pages ont été mises en cache par la première requête. Si vous effacez le cache avant chaque exécution, ils démarrent sur un pied d'égalité.
Si vous souhaitez tester les performances du cache dynamique, veillez à exécuter les requêtes plusieurs fois, en alternant, et à ignorer les deux premières exécutions. Moyenne des résultats.
Supposons que votre requête prenne une seconde par rapport à un cache chaud, mais une minute par rapport à un cache à froid. Une optimisation qui ralentit la requête en mémoire de 20% mais la requête liée aux entrées-sorties de 20% plus rapide pourrait être un avantage considérable: lors d'opérations normales, personne ne remarquera les 200 ms supplémentaires dans des circonstances normales, mais si quelque chose force une requête à courir sur le disque, prendre 48 secondes au lieu de 60 pourrait sauver une vente.
Cela pose moins de problèmes sur les systèmes modernes dotés de dizaines de giga-octets de mémoire et d'un stockage SAN et SSD relativement rapide, mais cela reste important. Si certains analystes exécutent une requête d'analyse de table volumineuse sur votre base de données OLTP qui efface la moitié de votre cache de mémoire tampon, les requêtes efficaces en termes de stockage vous permettront de revenir rapidement à la vitesse supérieure.
la source