Comment mesurer au mieux les performances des requêtes?

J'ai 2 procédures stockées, où la deuxième procédure stockée est une amélioration de la première.

J'essaie de mesurer exactement combien il s'agit d'une amélioration.

1 / La mesure clock timene semble pas être une option car j'ai des temps d'exécution différents. Pire encore, parfois (rarement, mais cela arrive), le temps d'exécution de la deuxième procédure stockée est plus long que le temps d'exécution de la première procédure (je suppose en raison de la charge de travail du serveur à ce moment).

2 / Include client statisticsfournit également des résultats différents.

3 / DBCC DROPCLEANBUFFERS, DBCC FREEPROCCACHEc'est bien, mais la même histoire ...

4 / SET STATISTICS IO ONpourrait être une option, mais comment puis-je obtenir un score global car j'ai de nombreuses tables impliquées dans mes procédures stockées?

5 / Include actual execution planpourrait être une option aussi. estimated subtreecostJ'obtiens un de 0,3253 pour la première procédure stockée et de 0,3079 pour la seconde. Puis-je dire que la deuxième procédure stockée est 6% plus rapide (= 0,3253 / 0,3079)?

6 / Utilisation du champ "Lectures" de SQL Server Profiler?

Alors, comment puis-je dire que la deuxième procédure stockée est x% plus rapide que la première procédure, quelles que soient les conditions d'exécution (la charge de travail du serveur, le serveur sur lequel ces procédures stockées sont exécutées, etc.)?

Si ce n'est pas possible, comment puis-je prouver que la deuxième procédure stockée a un meilleur temps d'exécution que la première procédure stockée?

J'aime utiliser l' outil gratuit SQLQueryStress pour comparer un scénario avant et après. Avec SQLQueryStress, vous pouvez exécuter chaque procédure stockée autant de fois que vous le souhaitez et obtenir les statistiques moyennes totales pour toutes les exécutions.

Par exemple, vous pouvez exécuter chaque procédure stockée 100 fois, puis utiliser les statistiques pour sauvegarder vos améliorations. "Plus de 100 exécutions, mes améliorations économisent un total de 30 secondes et le proc stocké fait 1500 lectures de moins par exécution." Je pense que vous avez l'idée.

S'il y a des paramètres dans le proc stocké, c'est toujours une bonne idée de vérifier que vos améliorations fonctionnent avec de nombreux ensembles de paramètres différents. SQLQueryStress fait des trucs sympas en vous permettant de substituer des paramètres dans votre requête pour obtenir une meilleure image globale de la façon dont le proc stocké pourrait fonctionner.

Documentation SQLQueryStress: http://www.datamanipulation.net/sqlquerystress/documentation/documentation.asp

4 / Vous pouvez aller sur http://statisticsioparser.com/statisticsioparser/ et coller vos statistiques afin de voir le score global.

Lorsque vous avez collecté des temps d'exécution sur quelques jours pour vos deux procédures stockées, je vous recommande d'utiliser cette page d'accueil

http://www.evanmiller.org/ab-testing/t-test.html

pour voir s'ils sont réellement différents.

La différence de 6% ne semble pas autant quand il s'agit d'améliorer les procédures stockées. J'en suis venu à attendre deux ordres de grandeur de mon collègue, et je fais semblant d'être déçu s'il n'atteint qu'un ordre de grandeur ...

Il n'a pas besoin d'utiliser la page d'accueil d'EvanMiller pour prouver que sa solution fonctionne plus rapidement.

Je voudrais également installer SQLSentrys (modifier :) Plan Explorer depuis http://www.sqlsentry.com/ car il s'agit d'un outil bien amélioré pour comparer les plans d'exécution.