Bienvenue à Blogs CodeS-SourceS Identification | Inscription | Aide

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 :
Publié mardi 17 avril 2007 16:30 par christian
Classé sous : ,

Commentaires

mardi 17 avril 2007 21:54 by cyril

# re: SQL Server : Comment mesure t’on la performance d’une requête ?

C'est ce qui est utilisé par le profiler pour obtenir les infos ?

En parlant de SQL profiler si t'avais un petit tuto qui explique comment bien l'utiliser et le comprendre pour un developpeur ...

mardi 17 avril 2007 22:40 by christian

# re: SQL Server : Comment mesure t’on la performance d’une requête ?

C'est à peu près les même suivant que l'on trace les batchs ou les requêtes... SQL Profiler fournis aussi les écritures.

pour un tuto pourquoi pas, je mets çà sur la pile... Ca devrait être possible pour 2010 :o>

Les commentaires anonymes sont désactivés

Les 10 derniers blogs postés

- Silverlight 3 : Communication et multicast par Kévin Gosse le il y a 4 heures et 0 minutes

- [Perso] Découvertes estivales : Linux (Part I) par Le blog de FremyCompany le il y a 6 heures et 42 minutes

- [Refactoring] ReSharper pour Visual Studio 2010 (Preview) par Thomas Jaskula le il y a 21 heures et 18 minutes

- [Refactoring] Analyser vos exceptions avec ReSharper Exceptional par Thomas Jaskula le il y a 22 heures et 32 minutes

- SharePoint 2007 : patterns & practices SharePoint Guidance par Philippe Sentenac [MVP SharePoint] le 07-03-2009, 09:56

- [Visual Studio 2010] Les tests cases c’est bien, mais je vais devoir tout réécrire ? par Etienne Margraff le 07-03-2009, 09:00

- MVP[Gribouillon].AddYear par The Grib's Lair [Sébastien PICAMELOT - MVP SharePoint] le 07-03-2009, 08:45

- Clinique INSIA - Projet de fin d’Etudes (Silverlight 3 MVVM et OutOfBrowser, WCF, TFS) - Part 1 par David REI le 07-02-2009, 23:38

- C’est la crise ? Bah pourquoi cramer du budget pub alors ? par Nix's Blog le 07-02-2009, 15:31

- Soyons MVP ! par TheSaib .NET blog le 07-02-2009, 12:15