Discussion :

[Etanne]

Bonjour à tous,

Je souhaiterai pouvoir comparer le temps d’exécution d'une requête. Pour cela j'ai essayé de la répéter quelques centaines de fois dans mon SQL Server Management Studio.

Pour information, je travail avec SQL SERVER 2008.

Comme ceci :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
SELECT * FROM T_PERSONNE
GO
SELECT * FROM T_PERSONNE
GO
...

Je divise ensuite le nombre de requête par le temps d'exécution pour obtenir le temps d'exécution moyen de ma requête.

Hélas, entre deux test de ce - benchmark - (a prendre bien entre des pincettes), les temps moyens sont vraiment différents d'une exécution à l'autre, et cela m’empêche de comparer avec d'autres type de requête comme par exemple :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

SELECT NOM, PRENOM, ADRESSE FROM T_PERSONNE

ou

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

SELECT NOM, PRENOM, ADRESSE FROM dbo.T_PERSONNE

J'avais tenté de faire cela :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
DECLARE @I INT 
SET @I =1 
 
WHILE @I < 300 
BEGIN 
	SELECT * FROM T_PERSONNE
END

Mais le delta entre deux exécutions sont toujours gênant pour bien se rendre compte de l'impact des différentes écritures possibles.

Auriez-vous une idée d'une bonne façon de procéder ?

Merci,
Etanne

[StringBuilder]

Vu qu'un SGBD est loin d'être stupide (et SQL Server fait partie de l'élite des intelligents) tu peux exécuter 1 fois pour 10000000000000000000000 fois de suite la même requête, seul le temps de la première sera significatif.

En effet, le moteur remarque immédiatement que c'est la même requête, et se contente de vérifier que les données n'ont pas changé depuis la dernière exécution... et il te renvoie le dernier résultat connu sans rejouer la requête...

[iberserk]

En effet, le moteur remarque immédiatement que c'est la même requête, et se contente de vérifier que les données n'ont pas changé depuis la dernière exécution... et il te renvoie le dernier résultat connu sans rejouer la requête...

????

Il est vrai qu'à la seconde exécution les données seront lue de la mémoire vive ce qui peut ne pas être la cas de la première...

De plus le plan d’exécution est en cache SQL SERVER n'a donc pas à le recalculer d'où une seconde exécution plus rapide...

Mais SQL SERVER refera tout de même la requète...

[Etanne]

Merci pour vos réponses.

J'avais complètement oublié les caches... ...de plus mon test était fait en réseau.

Bref, tout pour mettre en péril mon travail de recherche.

Il y a t-il des outils ou méthodes pour pouvoir comparer différentes requêtes, et avoir réellement le temps de traitement du moteur MSSQL ?

Par exemple :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
SELECT * FROM dbo.T_BUREAU
-- versus
SELECT * FROM T_BUREAU

Merci à tous ,
Etanne

[StringBuilder]

Le plan d'exécution.

Cependant, je ne vois pas quelle différence il peut y avoir entre les deux requêtes...

La table t_bureau existe avec plusieurs propriétaires différents ???

[Etanne]

Je cite par exemple SQLPro :

Ne pas utiliser les schémas en préfixe des objets est idiot, car cela posera des problèmes de performances : le SGBDR doit rechercher quel est le schéma à utiliser dans le contexte de lancement de la requête et cela peut varier d'un utilisateur à l'autre.

http://www.developpez.net/forums/d10...r/#post5848634

De ce que j'ai compris, il fallait préciser directement le schéma dans la requête.

J'ai mal compris ?

Merci !

[SQLpro]

Vu qu'un SGBD est loin d'être stupide (et SQL Server fait partie de l'élite des intelligents) tu peux exécuter 1 fois pour 10000000000000000000000 fois de suite la même requête, seul le temps de la première sera significatif.

En effet, le moteur remarque immédiatement que c'est la même requête, et se contente de vérifier que les données n'ont pas changé depuis la dernière exécution... et il te renvoie le dernier résultat connu sans rejouer la requête...

Non, cela est totalement faux. Sauf à utiliser SSAS et un cube OLAP.

A +