Il est toujours délicat de bien dimensionner une base de données Azure SQL Database. Pour choisir la bonne version à utiliser entre les Basic, Standart et Premium, il faut bien comprendre la notion de DTU (Database Throught Unit).

Le DTU est une unité de calcul basée sur l’activité de la base de données. Chaque requête / procédure stockée sur la base consomme un nombre de DTU. Chaque version de Azure SQL Database est capable d’absorder un nombre de DTU en simultané cappé : 5 pour l’édition de base, de 10 à 100 pour les éditions standard, et de 125 à 1000 pour l’édition Premium.

Quand la base de données arrive à 100% de sa capacité en DTU, les requêtes sont mises en attente avant d’être traitées, et les performances générales de la base et de l’appli l’utilisant deviennent logiquement dégradés.

Deux solutions sont possibles lorsque cette situation apparait :

• Augmenter (upscaller) la version de la base de données utilisée pour augmenter sa capacité de DTU. Cette opération s’effectue depuis le portail Azure et est appliquée en quelques minutes.
• Essayer d’analyser ce qui consomme du DTU pour réduire / optimiser l’utilisation.

C’est pour répondre à ce deuxième point que Microsoft Azure propose une nouvelle fonctionnalité, Query Performance Insight, actuellement en version Preview.

Query Performance Insight s’active depuis la version Preview d’Azure, sur le tableau de bord de la base de données à surveiller.

Une fois activé, ce module se met à enregistrer dans une table Azure Storage l’ensemble des requêtes effectuées sur la base, associé au nombre de DTU consommé par chacune.

A partir d’1h d’analyse, l’interface propose un graphique qui fait apparaitre, pour chaque heure d’analyse :

• Une courbe avec le % de DTU consommé
• Une barre qui met en évidence le cumulé des 5 ou 10 requêtes les plus consommatrices

Ceci est très intéressant pour se rendre compte des potentiels goulets d’étranglement qui impactent les performances. Dans l’exemple suivant, qui représente une vrai analyse de prod, on remarque qu’environ 1/3 du DTU est consommé par uniquement 2 requêtes (la requête 32 – en orange, exécutée 617 fois en 1 heure pour 16,76% de DTU, et la requête 14 en gris).

Pour zoomer sur la requête coupable de cette surchage, il suffit de cliquer sur son nom pour obtenir un graphique détaillé.

Et enfin, pour connaitre le code SQL coupable, le bouton Query Text en haut de l’interface permet d’afficher le contenu de la requête sur-utilisée.

Dans le cas présent, on remarque que le problème vient d’un appel LINQ mal utilisé qui génère une requête dont la syntaxe seule fait plus de 5000 lignes !

Il reste juste à retrouver le bout de code coupable de cet appel, de patcher et de valider l’impact sur les performances