Visualisering og fortolkning af forespørgselsdiagnosticering i Power BI
Introduktion
Når du har registreret den diagnosticering, du vil bruge, er det næste trin at kunne forstå, hvad de siger.
Det er nyttigt at have en god forståelse af, hvad præcis hver kolonne i skemaet til forespørgselsdiagnosticering betyder, hvilket vi ikke vil gentage i dette korte selvstudium. Der er en fuld skrive op af det her.
Generelt er det bedre at bruge den detaljerede tabel, når du opretter visualiseringer. Fordi uanset hvor mange rækker det er, er det, du sandsynligvis ser på, en form for skildring af, hvordan den tid, der er brugt i forskellige ressourcer, lægger sammen, eller hvad den oprindelige forespørgsel udsendte var.
Som nævnt i vores artikel om registrering af diagnosticering arbejder jeg med OData- og SQL-sporingerne for den samme tabel (eller næsten så) – tabellen Customers fra Northwind. Jeg vil især fokusere på almindelige forespørgsler fra vores kunder og et af de nemmere at fortolke sporingssæt: fuld opdatering af datamodellen.
Oprettelse af visualiseringerne
Når du gennemgår sporinger, er der mange måder, du kan evaluere dem på. I denne artikel vil vi fokusere på en to visualiseringsopdeling – en for at få vist de detaljer, du interesserer dig for, og den anden for nemt at se på tidsbidrag fra forskellige faktorer. For den første visualisering bruges der en tabel. Du kan vælge de felter, du vil, men dem, der anbefales til et nemt og højt niveau, ser på, hvad der foregår:
- Id
- Starttidspunkt
- Forespørgsel
- Trin
- Datakildeforespørgsel
- Eksklusiv varighed (%)
- Rækkeantal
- Kategori
- Er brugerforespørgsel
- Sti
For den anden visualisering er ét valg at bruge et stablet søjlediagram. I parameteren 'Akse' kan du bruge 'Id' eller 'Trin'. Hvis vi ser på Opdateringen, fordi den ikke har noget at gøre med trinnene i selve editoren, vil vi sandsynligvis bare se på 'Id'. For parameteren 'Forklaring' skal du angive 'Kategori' eller 'Handling' (afhængigt af den ønskede granularitet). For 'Værdi' skal du angive 'Eksklusiv varighed' (og sørg for, at det ikke er %, så du får værdien for rå varighed). Til sidst skal du for værktøjstippet angive 'Tidligste starttidspunkt'.
Når din visualisering er bygget, skal du sørge for at sortere efter 'Tidligste starttidspunkt' stigende, så du kan se den rækkefølge, tingene sker i.
Selvom dine nøjagtige behov kan variere, er denne kombination af diagrammer et godt sted at starte med at kigge på mange diagnosticeringsfiler og til en række formål.
Fortolkning af visualiseringerne
Som nævnt ovenfor er der mange spørgsmål, du kan prøve at besvare med forespørgselsdiagnosticering, men de to, som vi ser oftest, spørger, hvordan tiden bruges, og spørger, hvad forespørgslen, der sendes til kilden, er.
Det er nemt at spørge, hvordan tiden bruges, og det vil være det samme for de fleste connectors. En advarsel med forespørgselsdiagnosticering, som nævnt andre steder, er, at du får vist markant forskellige funktioner, afhængigt af connectoren. Mange ODBC-baserede connectors har f.eks. ikke en nøjagtig registrering af, hvilken forespørgsel der sendes til det faktiske back end-system, da Power Query kun ser, hvad den sender til ODBC-driveren.
Hvis vi vil se, hvordan tiden bruges, kan vi bare se på de visualiseringer, vi har bygget ovenfor.
Nu, da tidsværdierne for de eksempelforespørgsler, vi bruger her, er så små, hvis vi vil arbejde med, hvordan Power BI rapporterer tid, er det bedre, hvis vi konverterer kolonnen Eksklusiv varighed til 'Sekunder' i Power Query-editoren. Når vi har gjort dette, kan vi se på vores diagram og få en anstændig idé om, hvor tiden bruges.
For mine OData-resultater kan jeg på billedet se, at langt størstedelen af tiden blev brugt på at hente dataene fra kilden – hvis jeg vælger elementet 'Datakilde' i forklaringen, viser det mig alle de forskellige handlinger, der er relateret til at sende en forespørgsel til datakilden.
Hvis vi udfører alle de samme handlinger og opretter lignende visualiseringer, men med SQL-sporingerne i stedet for ODATA-sporene, kan vi se, hvordan de to datakilder sammenlignes!
Hvis vi vælger datakildetabellen, f.eks. med ODATA-diagnosticering, kan vi se den første evaluering (2.3 på dette billede) udsender metadataforespørgsler, hvor den anden evaluering faktisk henter de data, vi interesserer os for. Da vi henter små mængder data i dette tilfælde, tager de data, der trækkes tilbage, en lille mængde tid (mindre end en tiendedel af et sekund, før hele den anden evaluering finder sted, med mindre end 20. af et sekund til selve datahentning), men det vil ikke være tilfældet i alle tilfælde.
Som ovenfor kan vi vælge kategorien 'Datakilde' i forklaringen for at se de udsendte forespørgsler.
Graver ned i dataene
Se på stier
Når du ser på dette, hvis det ser ud til, at den tid, der er brugt, er underlig – for eksempel kan du i OData-forespørgslen se, at der er en datakildeforespørgsel med følgende værdi:
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>
Denne datakildeforespørgsel er knyttet til en handling, der f.eks. kun fylder 1 % af den eksklusive varighed. I mellemtiden er der en lignende:
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
Denne datakildeforespørgsel er knyttet til en handling, der fylder næsten 75 % af den eksklusive varighed. Hvis du slår Path til, opdager du, at sidstnævnte faktisk er underordnet den tidligere. Det betyder, at den første forespørgsel grundlæggende tilføjede en lille mængde tid alene, hvor den faktiske datahentning spores af den "indre" forespørgsel.
Disse er ekstreme værdier, men de er inden for grænserne af, hvad der kan ses.