SQL Server : Comment mesure t’on la performance d’une requête ?
Sur un système de base de données relationnelle comme SQL Server, on vérifie la performance de la requête entre autres sur son influence sur l'environnement matériel du serveur. Il y a 4 facteurs matériels : le ou les disque(s), le ou les processeur(s), la ou les interface(s) réseau, la mémoire. Pour simplifier je ne parlerais pas de la concurrence d'accès aux données ici.
Pour la partie réseau, ses performances dépendent du nombre de champs (et de leur taille) et du nombres d'enregistrement renvoyés, ainsi que du fait qu'elle impacte des champs long ou non (qui contiennent une grande taille, tels que varchar(max) ou image entre autres).
La consommation de mémoire est plus une question de cache, plus on en a disposition, plus on limite la consommation disque.
Les 2 facteurs essentiels sont le disque et le processeur. Or SQL Server nous fournis 2 commandes permettant de mesurer précisément la consommation de ces 2 ressources.
SET STATISTICS IO ON
SET STATISTICS TIME ON
-- Ma requête ici
SET STATISTICS TIME OFF
SET STATISTICS IO OFF
Pensez bien à remettre ces options à OFF, elles sont en effet valables pour la connexion jusqu'à sa fermeture sinon toutes les commandes verront leur statistiques renvoyés par la suite.
Vous obtiendrez en message pour le temps CPU :
SQL Server parse and compile time:
CPU time = 0 ms, elapsed time = 1 ms.
SQL Server Execution Times:
CPU time = 0 ms, elapsed time = 10 ms.
Le premier est le temps passé et le temps CPU nécessaire à la compilation de la requête, le second est celui nécessaire à l'exécution de la requête. Le premier n'apparait que si un plan d'exécution présent dans le cache n'a pas pu être réutilisé.
Au niveau des IO le message suivant vous est fourni :
Table 'Employee'. Scan count 0, logical reads 2, physical reads 2, read-ahead reads 0, lob logical reads 0, lob physical reads 0, lob read-ahead reads 0.
On l'on trouve la liste des tables, le nombre de scan (de passage que le moteur a du effectuer sur la table), puis le nombre de lectures. Le nombre de lectures représente le nombre de pages lues, une page étant de taille fixe (8 ko). Les lectures logiques sont effectuées dans le cache (en mémoire), les lectures physiques sont quant à elle effectuées sur le disque. Le read-ahead charge par avance des pages en mémoire pour les futurs besoins de la requête. Sur SQL Server 2005 la référence aux lectures de LOB (Large Objects) est aussi indiquée.
Le total des pages « physical reads » + « read-ahead reads » représente le nombre de pages lues sur le disque, ce chiffre varie énormément d'une exécution de requête à l'autre. Il permet essentiellement d'apprécier l'utilisation du cache et donc si la mémoire disponible est suffisante.
En sachant tout cela, optimiser la requête revient à diminuer le nombre de pages lues par le moteur et le temps processeur consommé.
Bonne optimisation…
Ce post vous a plu ? Ajoutez le dans vos favoris pour ne pas perdre de temps à le retrouver le jour où vous en aurez besoin :