Visualisation et interprétation des diagnostics de requête dans Power BI

Présentation

Une fois que vous avez enregistré les diagnostics que vous souhaitez utiliser, l’étape suivante est en mesure de comprendre ce qu’ils disent.

Il est utile d’avoir une bonne compréhension de ce que signifie exactement chaque colonne dans le schéma de diagnostic de requête, ce que nous n’allons pas répéter dans ce tutoriel court. Vous trouverez un compte-rendu complet de cela ici.

En général, lors de la création de visualisations, il est préférable d’utiliser la table détaillée complète. Étant donné que, peu importe le nombre de lignes, vous examinez probablement une sorte de représentation du temps passé dans différentes ressources, ou le résultat émis par la requête native.

Comme mentionné dans notre article sur l’enregistrement des diagnostics, je travaille avec les traces OData et SQL pour la même table (ou presque) : la table Customers de Northwind. En particulier, je vais me concentrer sur la demande commune de nos clients, et l’un des ensembles de traces plus faciles à interpréter : actualisation complète du modèle de données.

Création des visualisations

Lorsque vous parcourez des traces, il existe de nombreuses façons de les évaluer. Dans cet article, nous allons nous concentrer sur deux visualisations fractionnées - une pour afficher les détails qui vous importent, et l'autre pour analyser aisément les contributions temporelles des différents facteurs. Pour la première visualisation, une table est utilisée. Vous pouvez choisir les champs que vous aimez, mais ceux recommandés pour un aperçu simple et élevé de ce qui se passe sont :

• Id
• Heure de début
• Requête
• Step
• Requête de source de données
• Durée exclusive (%)
• Nombre de lignes
• Catégorie
• Est-ce une requête utilisateur ?
• Chemin d’accès

Pour la deuxième visualisation, un choix consiste à utiliser un histogramme empilé. Dans le paramètre « Axe », vous pouvez utiliser « Id » ou « Étape ». Si nous examinons l’actualisation, car elle n’a rien à voir avec les étapes de l’éditeur lui-même, nous voulons probablement simplement examiner « ID ». Pour le paramètre « Légende », vous devez définir « Catégorie » ou « Opération » (en fonction de la granularité souhaitée). Pour la valeur, définissez « Durée exclusive » (et assurez-vous qu’il ne s’agit pas de l'%, afin d’obtenir la valeur de durée brute). Enfin, pour l'info-bulle, définissez « Heure de début la plus tôt possible ».

Une fois votre visualisation générée, vérifiez que vous triez par ordre croissant « Heure de début la plus ancienne » afin de voir l’ordre dans lequel les choses se produisent.

Bien que vos besoins exacts diffèrent, cette combinaison de graphiques est un bon endroit pour commencer à examiner de nombreux fichiers de diagnostic et à plusieurs fins.

Interprétation des visualisations

Comme mentionné ci-dessus, il existe de nombreuses questions auxquelles vous pouvez essayer de répondre avec les diagnostics de requête, mais les deux que nous voyons le plus souvent sont demander comment le temps est utilisé et demander quelle est la requête envoyée à la source.

Demander comment le temps est utilisé est facile, ce qui sera similaire pour la plupart des connecteurs. Un des avertissements concernant les diagnostics de requête, comme mentionné dans d'autres contextes, est que vous pourriez constater des différences radicales dans les fonctionnalités selon le connecteur. Par exemple, de nombreux connecteurs ODBC n’ont pas d’enregistrement précis de la requête envoyée au système back-end réel, car Power Query voit uniquement ce qu’il envoie au pilote ODBC.

Si nous voulons voir comment le temps est passé, nous pouvons simplement examiner les visualisations que nous avons créées ci-dessus.

À présent, étant donné que les valeurs de temps des exemples de requêtes que nous utilisons ici sont si petites, si nous voulons utiliser la façon dont Power BI signale l’heure, il est préférable de convertir la colonne Durée exclusive en « Secondes » dans l’éditeur Power Query. Une fois cette conversion terminée, nous pouvons examiner notre graphique et avoir une idée claire de comment le temps est utilisé.

Pour mes résultats OData, je vois dans l’image que la grande majorité du temps a été passé à récupérer les données à partir de la source. Si je sélectionne l’élément « Source de données » sur la légende, il me montre toutes les différentes opérations liées à l’envoi d’une requête à la source de données.

Si nous effectuons toutes les mêmes opérations et créons des visualisations similaires, mais avec les traces SQL au lieu des opérations ODATA, nous pouvons voir comment les deux sources de données sont comparées !

Si nous sélectionnons la table de source de données, comme avec les diagnostics ODATA, nous pouvons voir la première évaluation (2.3 dans cette image) émet des requêtes de métadonnées, la deuxième évaluation récupérant réellement les données dont nous nous soucions. Étant donné que nous récupérons de petites quantités de données dans ce cas, les données extraites prennent un peu de temps (moins d’un dixième d’une seconde pour l’ensemble de la deuxième évaluation à effectuer, avec moins d’un xième de seconde pour la récupération de données elle-même), mais cela ne sera pas vrai dans tous les cas.

Comme ci-dessus, nous pouvons sélectionner la catégorie « Source de données » dans la légende pour afficher les requêtes émises.

Exploration des données

Examiner les chemins

Lorsque vous examinez cela, s’il semble que le temps passé soit étrange , par exemple, sur la requête OData, vous pouvez voir qu’il existe une requête de source de données avec la valeur suivante :

Request:
https://services.odata.org/V4/Northwind/Northwind.svc/Customers?$filter=ContactTitle%20eq%20%27Sales%20Representative%27&$select=CustomerID%2CCountry HTTP/1.1
Content-Type: application/json;odata.metadata=minimal;q=1.0,application/json;odata=minimalmetadata;q=0.9,application/atomsvc+xml;q=0.8,application/atom+xml;q=0.8,application/xml;q=0.7,text/plain;q=0.7

<Content placeholder>

Response:
Content-Type: application/json;odata.metadata=minimal;q=1.0,application/json;odata=minimalmetadata;q=0.9,application/atomsvc+xml;q=0.8,application/atom+xml;q=0.8,application/xml;q=0.7,text/plain;q=0.7
Content-Length: 435

<Content placeholder>

Cette requête de source de données est associée à une opération qui prend uniquement en charge, par exemple, 1% de la durée exclusive. Entre-temps, il y en a un similaire :

Request:
GET https://services.odata.org/V4/Northwind/Northwind.svc/Customers?$filter=ContactTitle eq 'Sales Representative'&$select=CustomerID%2CCountry HTTP/1.1

Response:
https://services.odata.org/V4/Northwind/Northwind.svc/Customers?$filter=ContactTitle eq 'Sales Representative'&$select=CustomerID%2CCountry
HTTP/1.1 200 OK

Cette requête de données est associée à une opération qui prend près de 75% de la durée exclusive. Si vous activez le Chemin, vous découvrez que ce dernier est en fait un enfant de l'autre. Cela signifie que la première requête a, de son propre fait, essentiellement ajouté une petite quantité de temps, avec la récupération réelle des données étant suivie par la requête « interne ».

Il s’agit de valeurs extrêmes, mais elles se trouvent dans les limites de ce qui peut être vu.