Bienvenue à Blogs CodeS-SourceS Identification | Inscription | Aide

Atteint de JavaScriptite Aiguë [Cyril Durand]

Expert ASP.net Ajax et WCF, Cyril Durand parle dans son blog de point techniques sur ASP.net, ASP.net Ajax, JavaScript, WCF et .net en général. Cyril est également consultant indépendant, n'hésitez pas à le contacter pour de l'assistance sur vos projets

Actualités

  • Blog de Cyril DURAND, passionné de JavaScript, Ajax, ASP.net et tout ce qui touche au developpement Web Client-Side.

    N'hésitez pas à me contacter pour vos projets .net : architecture, accompagnement, formation, ...

    View Cyril Durand's profile on LinkedIn
    hit counters


    Expertise Commerce server et BizTalk

Comment obtenir les indicateurs de performances d’une requête SQL avec SQL Server ?

Lorsque l’on réalise une application qui utilise un serveur de base de donnée, il est toujours intéressant de regarder quelles sont les performances des requêtes SQL que notre application exécute.

Il y a plusieurs solutions pour arriver à ces fins.

La première, la plus connue, est d’utiliser SQL Server Profiler. Il s’agit d’un outil qui va analyser tout ce qui transite sur le serveur SQL.

Lorsque vous lancez l’outil, il va d’abord vous demander de vous connecter sur un serveur SQL, puis, il va vous demander un template. Un template est un ensemble de règle qui permet de tracer seulement certains événements. Je trouve que le template par défaut log trop de choses et qu’il manque certaines données importantes.

Pour ma part, je ne logge que ces informations :

image

J’ai rajouté la colonne “RowCounts” qui permet de savoir le nombre de ligne retourné par la requête, et supprimé les événements “RPC:Starting” et “SQL:BatchStarting” qui surgisse dès le début de la requête, avant même que SQL ait commencé l’analyse.

Ensuite, après avoir configuré la trace, vous allez voir apparaitre les différentes requêtes qui sont jouées sur votre serveur.

image

Les colonnes intéressantes sont les colonnes :

  • CPU : nombre d’unité de CPU consommé (unité arbitraire)
  • Reads : nombre de pages lues
  • Writes : nombre de pages écrites
  • Duration : durée d’éxécution en ms
  • RowCounts : nombre de ligne retourné par la requête

Il est également possible de mettre des flags au niveau de votre session SQL Server, ainsi pour chaque batch de votre session, vous aurez le détail des accès disques et durée d’exécution. Les flags à spécifier sont les flags suivants :

set statistics io on 
set statistics time on 

select * 
from magelia.Address 
where Name = 'home'

Au niveau des messages vous obtiendrez alors :

SQL Server parse and compile time: 
   CPU time = 0 ms, elapsed time = 0 ms.

 SQL Server Execution Times:
   CPU time = 0 ms,  elapsed time = 0 ms.

 SQL Server Execution Times:
   CPU time = 0 ms,  elapsed time = 0 ms.
SQL Server parse and compile time: 
   CPU time = 0 ms, elapsed time = 0 ms.

(8142 row(s) affected)
Table 'Address'. Scan count 1, logical reads 2775, physical reads 0, read-ahead reads 0, lob logical reads 5496, lob physical reads 0, lob read-ahead reads 5242.

 SQL Server Execution Times:
   CPU time = 78 ms,  elapsed time = 778 ms.

 SQL Server Execution Times:
   CPU time = 78 ms,  elapsed time = 778 ms.

Ne vous focalisez pas sur le temps d’exécution ! Lorsque vous êtes tous seul sur votre base de données, le disque dur est peu sollicité, les durées d’exécution seront globalement bonnes. Par contre, focalisez-vous sur le nombre de pages lues : ce qui est couteux sur un serveur SQL est les accès disques. Il est donc préférable d’avoir une requête qui consomme très peu de pages lues plutôt qu’une requête un peu plus rapide qui consomme beaucoup plus de pages lues.

Et vous qu’utilisez-vous pour connaitre les performances des requêtes SQL que vous écrivez ?

Posted: lundi 9 janvier 2012 20:14 par cyril
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 :

Commentaires

Aurelien a dit :

Pour de la performance sur une requête, j'utilise le même procédé.

Pour une vue d'ensemble sur les bottleneck, je préfère SQLNexus (http://sqlnexus.codeplex.com/)

# janvier 10, 2012 11:26
Les commentaires anonymes sont désactivés

Les 10 derniers blogs postés

- La feuille de route NON-OFFICIELLE d’Office 365 – De MS Ignite 2015 à MS Ignite 2016 par Le blog de Patrick [MVP Office 365] le 07-23-2015, 14:04

- 24 heures de conférence en ligne #Collab365 ! par Le blog de Patrick [MVP Office 365] le 07-21-2015, 18:12

- « Festival Clin d‘Œil » à Reims par Blog de Jérémy Jeanson le 07-03-2015, 14:43

- Que peut-on gagner à avoir des applications accessibles ? par Blog de Jérémy Jeanson le 07-03-2015, 14:26

- SharePoint 2007: Forcer le mode compatibilité depuis IIS par Blog Technique de Romelard Fabrice le 07-01-2015, 16:41

- [VBA] Manipuler un SQL Server sans risque par Blog de Jérémy Jeanson le 06-13-2015, 11:48

- Témoignage sur le rôle d’architecte logiciel par Blog de Jérémy Jeanson le 06-13-2015, 11:34

- NCrafts : Machine learning the F# way par Aurélien GALTIER le 06-04-2015, 11:22

- Configuration de Workflow Manager 1.0 pour SharePoint 2013 et ses soucis. par The Mit's Blog le 06-01-2015, 18:04

- TFS 2013 : Migration d’une ferme TFS 2005 vers 2013 sans Upgrade par Blog Technique de Romelard Fabrice le 06-01-2015, 11:22