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/Mesurer clock time ne semble pas être une option car j'obtiens 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 statistics fournit également des résultats différents.
3/DBCC DROPCLEANBUFFERS, DBCC FREEPROCCACHE sont bons, mais la même histoire ...
4/SET STATISTICS IO ON pourrait être une option, mais comment obtenir un score global car j'ai plusieurs tables impliquées dans mes procédures stockées?
5/Include actual execution plan pourrait également être une option. Je reçois un estimated subtreecost 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 quelques 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 à partir de http://www.sqlsentry.com/ car il s'agit d'un outil bien amélioré pour comparer les plans d'exécution.