Visualisering og tolkning av spørringsdiagnostikk i Power BI

Innføring

Når du har registrert diagnostikken du vil bruke, er neste steg å kunne forstå hva de sier.

Det er nyttig å ha en god forståelse av hva hver kolonne i spørringsdiagnostikkskjemaet egentlig betyr, noe vi ikke kommer til å gjenta i denne korte veiledningen. Det finnes en fullstendig beskrivelse av det her.

Generelt, når du lager visualiseringer, er det bedre å bruke den fullstendige detaljerte tabellen. For uansett hvor mange rader det er, ser du sannsynligvis på en slags fremstilling av hvordan tiden brukt på ulike ressurser summerer seg opp, eller hva den opprinnelige spørringen var.

Som nevnt i artikkelen vår om registrering av diagnostikk, jobber jeg med OData- og SQL-sporene for samme tabell (eller nesten) – Customers-tabellen fra Northwind. Spesielt vil jeg fokusere på vanlige krav fra kundene våre, og et av de lettere å tolke sporene: full oppdatering av datamodellen.

Bygging av visualiseringene

Når du går gjennom spor, finnes det mange måter du kan evaluere dem på. I denne artikkelen skal vi fokusere på to visualiseringsfordelinger – én for å vise detaljene du bryr deg om, og én for enkelt å se på tidsbidrag fra ulike faktorer. For den første visualiseringen brukes en tabell. Du kan velge hvilke felt du vil, men de som anbefales for en enkel, overordnet oversikt over hva som skjer er:

• Id
• Starttid
• Spørsmål
• Skritt
• Datakildespørring
• Eksklusiv varighet (%)
• Radtelling
• Kategori
• Er brukerspørring
• Sti

For den andre visualiseringen er et valg å bruke et stablet kolonnediagram. I parameteren 'Axis' kan du bruke 'Id' eller 'Step'. Hvis vi ser på Refresh, fordi den ikke har noe med steg i selve Editoren å gjøre, vil vi sannsynligvis bare se på 'Id'. For parameteren 'Legend' bør du sette 'Kategori' eller 'Operasjon' (avhengig av hvilken granularitet du ønsker). For 'Verdi', sett 'Eksklusiv varighet' (og sørg for at det ikke er %, slik at du får rå varighetsverdi). Til slutt, for verktøytipset, sett 'Tidligste starttid'.

Når visualiseringen din er bygget, sørg for å sortere etter 'Tidligste starttidspunkt' stigende, slik at du kan se rekkefølgen ting skjer i.

Selv om dine eksakte behov kan variere, er denne kombinasjonen av diagrammer et godt sted å starte for å se på mange diagnostiske filer og til flere formål.

Tolkning av visualiseringene

Som nevnt ovenfor, er det mange spørsmål du kan prøve å svare på med spørringsdiagnostikk, men de to vi oftest ser er hvordan tiden brukes, og hva spørringen som sendes til kilden er.

Å spørre hvordan tiden brukes er enkelt, og vil være likt for de fleste kontakter. En advarsel med spørringsdiagnostikk, som nevnt andre steder, er at du vil se drastisk forskjellige funksjoner avhengig av kontakten. For eksempel vil mange ODBC-baserte kontakter ikke ha en nøyaktig registrering av hvilken spørring som sendes til det faktiske backend-systemet, siden Power Query kun ser hva den sender til ODBC-driveren.

Hvis vi vil se hvordan tiden brukes, kan vi bare se på visualiseringene vi har laget ovenfor.

Nå, fordi tidsverdiene for eksempelspørringene vi bruker her er så små, hvis vi vil jobbe med hvordan Power BI rapporterer tid, er det bedre å konvertere kolonnen Eksklusiv varighet til 'Sekunder' i Power Query-editoren. Når vi har gjort denne konverteringen, kan vi se på horoskopet vårt og få en god idé om hvor tiden brukes.

For mine OData-resultater ser jeg på bildet at mesteparten av tiden ble brukt på å hente data fra kilden—hvis jeg velger 'Data Source'-elementet i legenden, viser den meg alle de ulike operasjonene knyttet til å sende en spørring til datakilden.

Hvis vi utfører alle de samme operasjonene og bygger lignende visualiseringer, men med SQL-sporene i stedet for ODATA-sporene, kan vi se hvordan de to datakildene sammenlignes!

Hvis vi velger Data Source-tabellen, som med ODATA-diagnostikkene, kan vi se at den første evalueringen (2.3 i dette bildet) sender ut metadata-spørringer, mens den andre evalueringen faktisk henter dataene vi bryr oss om. Fordi vi henter små mengder data i dette tilfellet, tar dataene som hentes tilbake en liten mengde tid (mindre enn en tidel sekund for hele den andre evalueringen, med mindre enn en tjuendedel av et sekund for selve datainnhentingen), men det vil ikke være tilfelle i alle tilfeller.

Som ovenfor kan vi velge kategorien 'Datakilde' i legenden for å se de utsendte spørringene.

Å grave i dataene

Ser på stier

Når du ser på dette, hvis det virker merkelig tid brukt – for eksempel, på OData-spørringen kan du se at det finnes en Data Source Query med følgende verdi:

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 datakildespørringen er knyttet til en operasjon som kun tar opp for eksempel 1% av den eksklusive varigheten. I mellomtiden finnes det 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ørselen er knyttet til en operasjon som opptar nesten 75% av den eksklusive varigheten. Hvis du slår på Veien, oppdager du at sistnevnte faktisk er et barn av førstnevnte. Dette betyr at den første spørringen i praksis la til en liten mengde tid alene, med selve datainnhentingen sporet av den 'indre' spørringen.

Dette er ekstreme verdier, men de ligger innenfor grensene for hva man kan se.