Voorbeeld van prestatieanalyse

Om de video-instructies te volgen, open het voorbeeldrapport hier.

Hoe het prestatierapport te interpreteren

Met HQbird, of als aparte service, IBSurgeon Performance Analysis via cc.ib-aid.com, kunt u een prestatierapport genereren op basis van Firebird trace-logs.

Dit rapport is een krachtig diagnostisch hulpmiddel dat gedetailleerde informatie biedt over de uitvoering van SQL-query’s in Firebird-databases. Deze handleiding legt uit hoe u trace-rapporten interpreteert en gebruikt om prestatieknelpunten systematisch te identificeren en op te lossen.

1. Structuur van het prestatierapport

┌─────────────────────────────────────────┐
│         Prestatierapport                │
├─────────────────────────────────────────┤
│ 1. Prestatiesamenvattingsgrafieken      │
│    ┌────────────────────────┐           │
│    │  Top-query's           │           │
│    │     Top-samenvatting   │           │
│    │     Top-frequentie     │           │
│    │     Duur               │           │
│    │     Fetches            │           │
│    │     Reads              │           │
│    │     Writes             │           │
│    │  Tijdreeksdiagram      │           │
│    │     Duur               │           │
│    │     Aantal query's     │           │
│    │     Fetches            │           │
│    │     Reads/Writes       │           │
│    └────────────────────────┘           │
├─────────────────────────────────────────┤
│ 2. Top-query's-analyse                  │
│    ┌────────────────────────┐           │
│    │ Query-ranglijsten      │           │
│    │                        │           │
│    │  Op duur──────────┐    │           │
│    │                   │    │           │
│    │  Op tijd──────────┤    │           │
│    │  Samenvatting     │    │           │
│    │                   │    │           │
│    │  Op plan──────────┤    │           │
│    │  Samenvatting     │    │           │
│    │                   │    │           │
│    │  Op frequentie────┤    │           │
│    │                   │    │           │
│    │  Op plan──────────┤    │           │
│    │  Frequentie       │    │           │
│    │                   │    │           │
│    │  Op fetches───────┤    │           │
│    │                   │    │           │
│    │  Op reads─────────┤    │           │
│    │                   │    │           │
│    │  Op writes────────┘    │           │
│    │                        │           │
│    └────────────────────────┘           │
├─────────────────────────────────────────┤
│ 3. Processamenvatting                   │
│    ┌────────────────────────┐           │
│    │ Statistieken per proces│           │
│    │ - Aantal uitvoeringen  │           │
│    │ - Fetches, enz.        │           │
│    │ - Duurmetrieken        │           │
│    └────────────────────────┘           │
├─────────────────────────────────────────┤
│ 4. Adressamenvatting                    │
│    ┌────────────────────────┐           │
│    │ Statistieken per       │           │
│    │ clientadres            │           │
│    │ - Aantal verbindingen  │           │
│    │ - Duur                 │           │
│    │ - Fetches, enz.        │           │
│    │ - Procesnamen          │           │
│    └────────────────────────┘           │
└─────────────────────────────────────────┘

Structuur van query-details:
┌────────────────────┐
│ Query-informatie   │
├────────────────────┤
│ - SQL-tekst        │
│ - Transactie-info  │
│ - Uitvoeringsplan  │
│ - Duurstatistieken │
│ - Bronstatistieken │
│   * Fetches        │
│   * Reads          │
│   * Writes         │
│   * Marks          │
│ - Clientinformatie │
└────────────────────┘

Het prestatierapport biedt een hiërarchische weergave van database-activiteit:

1. Prestatiesamenvattingsgrafieken

• Visuele weergave van belangrijke metrieken in de tijd - u kunt eenvoudig pieken in activiteit/belasting zien. (Er is ook een per-minuut-analyserapport beschikbaar in Advanced Performance Monitoring in HQbird; de verkorte versie hiervan is beschikbaar op de Portal-tool - zie deze video voor details).

• Helpt patronen en afwijkingen te identificeren: het vergelijken van grafieken uit periodes met goede prestaties (bijv. vorige week/maand) met prestatieproblemen kan helpen het probleem te identificeren.

2. Top-query’s-analyse

• Meerdere rangschikkingsperspectieven voor uitgebreide analyse: de langste query’s, de meest frequente query’s, de meest tijdrovende query’s (gegroepeerd op tekst of plan), en meer.

• Elke dimensie onthult verschillende optimalisatiemogelijkheden

• Gedetailleerde statistieken voor elke query, waaronder:

• Duurmetrieken (min, max, gemiddelde, mediaan)

• Bronverbruik (fetches, reads, writes)

• Uitvoeringspatronen - aantal herkomsten voor de top-query’s.

3. Processamenvatting

• Groepeert statistieken per uitvoerend proces

• Helpt problematische applicaties te identificeren

• Toont bronverbruik en databasebewerkingen (verbindingen, query’s, enz.) en metrieken (fetches, reads, enz.) per proces

4. Adressamenvatting

• Groepeert statistieken per clientverbinding

• Onthult de belastingsverdeling over clients

• Helpt verbindingsspecifieke problemen te identificeren

Elke sectie ondersteunt prestatieanalyse op verschillende niveaus:

• Systeembrede patronen (grafieken) - zie wanneer en waar problemen in het algemeen optreden.

• Meest opvallende impact van query’s (top-query’s) - identificeer query’s die eerst geoptimaliseerd moeten worden.

• Problemen op applicatieniveau (processamenvatting) - identificeer applicaties die prestatieproblemen veroorzaken.

• Problemen op clientniveau (adressamenvatting) - identificeer IP-adressen (werkstations, clientcomputers) met de grootste stroom aan query’s.

2. Tijdssamenvatting en plansamenvattingsanalyse

Het wordt aanbevolen om een analyse van de prestatiesituatie te starten met de samenvattingssecties. Klik hier om de plansamenvattingssectie in het voorbeeldrapport te openen.

De tijdssamenvatting aggregeert de totale uitvoeringstijd voor elk uniek SQL-statementpatroon.

Beschouw het als een “kostenplaats”-rapport dat laat zien welke query’s in de loop van de tijd de meeste databasebronnen verbruiken.

Als query's niet geparametriseerd zijn, d.w.z. expliciet parameterwaarden in de SQL-tekst bevatten in plaats van parameterplaatsaanduidingen (:myparam1), is het noodzakelijk om de sectie "Plan-Samenvatting" te gebruiken om query's met de hoogste frequentie te identificeren.
Voorbeeld van een niet-geparametriseerde query: 'SELECT * FROM COUNTRY WHERE COUNTRYID=2'
Voorbeeld van een geparametriseerde query: 'SELECT * FROM COUNTRY WHERE COUNTRYID=:paramid'

Elke query in de samenvattingssectie heeft een koptekst met de volgende belangrijke onderdelen:

• Samenvatting: Percentage van de totale tijd, het toont welk deel van de totale database-tijd een query verbruikt.

• Frequentie: Hoe vaak het querypatroon voorkomt

• Fetch, Read, Write: bronmetrieken

Bijvoorbeeld, als er staat

Samenvatting: 19.08% (3920272 van 20541791 ms)

Dit vertelt ons dat dit querypatroon bijna 20% van de totale database-tijd verbruikt - een aanzienlijk deel dat onmiddellijke aandacht vereist.

Onder de koptekst in de plansamenvattingssectie zien we het SQL-uitvoeringsplan dat is gebruikt om query’s te groeperen; in de tijdssamenvatting is dit de tekst van de query zelf.

Aangezien een querypatroon meer dan één specifieke query vertegenwoordigt, wordt de verbindingsspecifieke informatie overgenomen van de eerste query die overeenkomt met het patroon:

Op de bovenstaande schermafbeelding ziet u de koptekst van een voorbeeldstatement voor het patroon; deze bestaat uit de applicatienaam die deze SQL heeft gestart, het verbindings-ID en het transactie-ID, evenals het IP-adres en de transactiedetails.

Hieronder volgen het plan (voor tijdssamenvatting; voor plansamenvatting wordt dit overgeslagen omdat het al aan het begin wordt getoond), parameterwaarden (in volgorde van verschijnen) en statistieken per tabel:

Houd er rekening mee dat we in de plansamenvatting SQL’s groeperen op basis van het uitvoeringsplan; dit betekent dat alleen het plan consistent is voor het patroon, en voor de tijdssamenvatting groeperen we op basis van de SQL-statementtekst, en andere zaken (parameterwaarden, uitvoeringstijden, enz.) kunnen verschillen. Gebruik deze informatie als voorbeeld van het uitvoeringspatroon (in 99% van de gevallen is dit voldoende om het probleem te reproduceren).

Hieronder hebben we een individuele grafiek met uitvoeringen van deze specifieke query. Zoals u kunt zien, werd deze query gestart in de periode van hoge belasting die we op de overzichtsgrafiek opmerkten.

En tot slot hebben we een zeer belangrijke verzameling statistieken voor ALLE query’s die overeenkomen met het patroon, en een lijst met herkomstadressen:

In deze statistieken zien we de minimale, maximale, gemiddelde en mediane uitvoeringstijden, evenals dezelfde statistieken voor fetches, reads, writes en marks (cache-flushbewerkingen).

2.1. Hoe de tijdssamenvatting te gebruiken:

• Identificeer eerst query’s die onevenredig veel tijd verbruiken (dit zijn de top 3 van deze sectie - #1, 2, 3)

• Vergelijk tijdverbruik met frequentie

• Bekijk de gemiddelde uitvoeringstijd (totale tijd / frequentie) onderaan de querysectie (zie hieronder)

• Zoek naar patronen waarbij:

• Hoge tijd + Lage frequentie = Inefficiënte individuele query’s

• Hoge tijd + Hoge frequentie = Mogelijk inefficiënte maar zwaar gebruikte query’s

3. Frequentieanalyse: Frequentie en Planfrequentie

Gebruik frequentieanalyse om te begrijpen hoe vaak query’s worden uitgevoerd. Beschouw het als het tellen van hoe vaak een bepaalde weg tijdens de spits wordt gebruikt.

Als query's niet geparametriseerd zijn, d.w.z. expliciet parameterwaarden in de SQL-tekst bevatten in plaats van parameterplaatsaanduidingen (:myparam1), is het noodzakelijk om de sectie "Plan-Samenvatting" te gebruiken om query's met de hoogste frequentie te identificeren.
Voorbeeld van een niet-geparametriseerde query: 'SELECT * FROM COUNTRY WHERE COUNTRYID=2'
Voorbeeld van een geparametriseerde query: 'SELECT * FROM COUNTRY WHERE COUNTRYID=:paramid'

3.1. De impact van frequentie begrijpen

De weergave van een frequentiequerypatroon lijkt sterk op de plan-/tijdssamenvatting:

Hoogfrequente query’s zijn als drukke kruispunten - zelfs als elke auto (query) snel beweegt, kan het enorme volume congestie veroorzaken. Dit beïnvloedt:

• Databaseverbindingen (zoals parkeerplaatsen - beperkt in aantal)

• Netwerkbandbreedte (zoals wegcapaciteit)

• CPU-gebruik (zoals verkeersleiders die overweldigd raken)

• Cache-efficiëntie (zoals herhaaldelijk dezelfde informatie moeten opvragen)

Om de impact van queries met hoge frequentie te schatten, verzamel een trace met parameterdrempel = 0.

3.2. Categorieën van Frequentie-impact

3.3. Voorbeeldanalyse

Laten we een reëel geval uit ons tracerapport bekijken:

Frequentie: 4.428 uitvoeringen (24,43% van totaal)
Impact: Kritiek - hoog volume aan SALES-tabellenqueries
Hoofdoorzaak: Herhaalde controles van klantsaldi
Optimalisatieprioriteit: Hoog

Uitleg: Deze query draait duizenden keren, vergelijkbaar met een
druk kruispunt. Zelfs als elke uitvoering snel is, is de
cumulatieve impact aanzienlijk. De applicatie controleert mogelijk
saldo's vaker dan nodig is.

4. Analyse van statistieken van top queries in xx-Samenvatting en Frequentie-secties

Bij het analyseren van Firebird-tracerapporten bevat elke querygroepering gedetailleerde geaggregeerde statistieken die cruciale inzichten bieden in prestatiepatronen. Laten we elke metriek opsplitsen en de betekenis ervan voor database-optimalisatie begrijpen.

4.1. Analyse van geaggregeerde statistieken

Laten we dit voorbeeld van statistieken bekijken:

Totaal: 4428 items:
Duren: min: 351; max: 3919; gem: 457,70; mediaan: 455,00; som: 2026710 (20,29%);
Fetches: min: 7135; max: 7168; gem: 7146,86; mediaan: 7147,00; som: 31646289 (0,75%);
Schrijfbewerkingen: min: 0; max: 0; gem: 0,00; mediaan: 0,00; som: 0 (0,00%);
Leesbewerkingen: min: 0; max: 6995; gem: 3,13; mediaan: 0,00; som: 13856 (8,22%);
Marks: min: 0; max: 0; gem: 0,00; mediaan: 0,00; som: 0 (0,00%);
Van 1 uniek adres: TCPv6:::1 (4428)

4.2. Analyse van uitvoeringsaantallen

4.2.1. Totaal aantal items

Totaal: 4428 items

Dit vertegenwoordigt het aantal keren dat dit specifieke querypatroon werd uitgevoerd tijdens de traceperiode.

Inzicht in dit aantal helpt u:

• Brongebruik per uitvoering berekenen

• Bepalen of querycaching nuttig kan zijn (of de query simpelweg minder vaak uitvoeren)

Hoge uitvoeringsaantallen kunnen wijzen op mogelijkheden voor:

• Implementeren van voorbereide statements (en geparametriseerde) - dezelfde query met dezelfde frequentie, wanneer geparametriseerd en voorbereid voor herhaalde uitvoering, vereist minder bronnen

• Toevoegen van resultaatcaching - het cachen van de resulterende waarde voor gebruik tijdens de lange bewerking of zelfs langer, voor de sessie van de gebruiker, kan de noodzaak om de query frequent uit te voeren verminderen

• Batchbewerkingen - overweeg de query uit te voeren om veel records tegelijk te retourneren of te verwerken, dit elimineert de overhead voor het uitvoeren van de query (voorbereiding, netwerktransmissie, enz.).

4.3. Duurmetrieken

4.3.1. Voorbeeld van duurcomponenten

Duren: min: 351; max: 3919; gem: 457,70; mediaan: 455,00; som: 2026710 (20,29%);

4.3.2. Duuranalyse

• Nauwe mediaan en gemiddelde (457,70 vs 455,00 ms) suggereren consistente prestaties

• Max/min-verhouding (~11x) duidt op enige variabiliteit

• 20,29% van de totale tijd is aanzienlijk - staat deze query in de top 3 van de Frequentie- of Plan-Frequentie-sectie? (ja, dat is zo.)

4.4. Metrieken voor brongebruik

4.4.1. Fetch-bewerkingen

Fetches: min: 7135; max: 7168; gem: 7146,86; mediaan: 7147,00; som: 31646289 (0,75%);

Fetches vertegenwoordigen het ophalen van rijen:

• Consistente fetch-aantallen (min/max-verschil van slechts 33) suggereren stabiele resultaatsets

• Relatief hoge fetch-aantallen (>7000 per uitvoering) kunnen duiden op:

• Noodzaak voor het beperken van de resultaatset en/of paginering, als er veel records worden geretourneerd.

• Potentieel voor query-optimalisatie - vooral zinvol als de query in de top 3 van Frequentie/Plan-Frequentie staat.

4.5. Leesbewerkingen

Leesbewerkingen: min: 0; max: 6995; gem: 3,13; mediaan: 0,00; som: 13856 (8,22%);

Fysieke leesbewerkingen duiden op schijftoegang:

• Nul mediaan met niet-nul maximum suggereert incidentele cachemissers

• 8,22% van het totale aantal leesbewerkingen duidt op matige I/O-impact

• Grote kloof tussen min (0) en max (6995) suggereert variabele cache-effectiviteit.

4.6. Schrijfbewerkingen

Schrijfbewerkingen: min: 0; max: 0; gem: 0,00; mediaan: 0,00; som: 0 (0,00%);

Als de query geen schrijfbewerkingen uitvoert, is het meestal een alleen-lezen bewerking.

4.7. Mark-bewerkingen

Marks: min: 0; max: 0; gem: 0,00; mediaan: 0,00; som: 0 (0,00%);

Mark-bewerkingen hebben betrekking op cachebeheer van gegevenspagina’s:

• Nul marks duiden aan dat geen gegevenspagina is gemarkeerd voor flushing, gebruikelijk voor eenvoudige SELECT-queries

• Niet-nul marks-bewerking met cache

4.8. Analyse van clientverbindingen

Van 1 uniek adres: TCPv6:::1 (4428)

Dit toont de bronverdeling van de query:

• Enkel clientadres suggereert een applicatiespecifieke query

• Lokale verbinding (::1 is IPv6 localhost)

• Alle 4428 uitvoeringen van dezelfde bron

4.9. Deze metrieken gebruiken voor optimalisatie

4.9.1. Analyse van prestatiepatronen

Uitvoeringsconsistentie

• Vergelijk min/max-duren

• Zoek naar uitschieters in brongebruik

• Controleer mediaan versus gemiddelde voor variabiliteit

Patronen in brongebruik

• Hoge fetches → Beoordeel de grootte van de resultaatset

• Hoge leesbewerkingen → Controleer indexdekking

• Hoge marks → Onderzoek lock-contentie

Analyse van clientimpact

• Meerdere clients → Grootte van de verbindingspool

• Enkele client → Applicatie-optimalisatie

4.9.2. Optimalisatieprioriteiten

Op basis van deze metrieken, prioriteer:

• Grootte van de resultaatset

• 7000 fetches per uitvoering

• Overweeg LIMIT/OFFSET toe te voegen

• Beoordeel de SELECT-kolomlijst

Cachingstrategie

• Frequente uitvoering (4428 keer)

• Consistente resultaatgrootte

• Geen schrijfbewerkingen betrokken

Waarschijnlijk kan deze query minder vaak worden uitgevoerd.

Indexgebruik

• Variabele leesbewerkingsaantallen

• Nul mediaan leesbewerkingen maar hoog maximum

• Beoordeel indexdekking

5. Praktische toepassing

Voor dit specifieke voorbeeld:

Verbeteringen op korte termijn:

• Implementeer resultaatcaching (hoog uitvoeringsaantal, consistente fetches)

• Beoordeel de grootte van de resultaatset (>7000 fetches per uitvoering)

Optimalisatie op middellange termijn:

• Analyseer indexgebruikspatronen

• Overweeg gebruik van voorbereide statements

• Beoordeel applicatielogica voor uitvoeringsfrequentie

Overwegingen op lange termijn:

• Monitor uitvoeringspatronen in de loop van de tijd

• Plan een indexonderhoudsstrategie

• Overweeg wijzigingen in gegevenstoegangspatronen

6. Duuranalyse

Duuranalyse onderzoekt hoe lang individuele queries nodig hebben om uit te voeren. Denk aan duur als een stopwatch die elke query timet - hoe langer een query duurt, hoe waarschijnlijker het is dat deze prestatieproblemen veroorzaakt.

6.1. Duurmetrieken begrijpen

Duurmetrieken zijn cruciaal omdat ze direct de gebruikerservaring beïnvloeden, d.w.z. gebruikers klagen dat “het systeem traag is”. Net zoals klanten gefrustreerd raken door lang wachten in een rij, raken gebruikers gefrustreerd wanneer queries te lang duren om te voltooien. Langlopende queries veroorzaken:

• Slechte gebruikerservaring wanneer schermen te lang laden

• Systeembronnen die langdurig bezet zijn

• Andere queries die in de rij wachten achter trage queries

• Mogelijke time-outproblemen in applicaties

6.2. Impactcategorieën

6.3. Voorbeeldanalyse

Duur: 77.793ms
Impact: Kritiek - enkele query verbruikt 77,7 seconden
Hoofdoorzaak: Complexe aggregatie in PRC_COLLECT_RANKCATEGORY
Optimalisatieprioriteit: Onmiddellijk

Uitleg: Deze query duurt meer dan een minuut om uit te voeren, wat lijkt op
een volledige verkeersstop. De opgeslagen procedure verwerkt waarschijnlijk
te veel gegevens of gebruikt inefficiënte algoritmen.

7. Implementatiestrategie

Denk aan optimalisatie als het verbeteren van een transportsysteem - u moet problemen identificeren, oplossingen plannen en wijzigingen zorgvuldig implementeren.

7.1. Prioriteitenmatrix

Deze matrix helpt u beslissen wat eerst aandacht nodig heeft, zoals het triëren van verkeersproblemen in een stad:

7.2. Stapsgewijs optimalisatieproces

1. Identificeer kritieke queries

• Zoek naar de grootste verkeersopstoppingen (trage queries)

• Vind de drukste kruispunten (queries met hoge frequentie)

• Spot inefficiënte routes (hoog brongebruik)

2. Analyseer uitvoeringsplannen

• Bestudeer huidige routes (indexgebruik)

• Onderzoek verkeerspatronen (join-methoden)

• Controleer knelpunten (sorteerbewerkingen)

3. Implementeer optimalisaties

• Bouw nieuwe wegen (indexen)

• Ontwerp routes opnieuw (herstructureer queries)

• Voeg snelkoppelingen toe (caching)

4. Verifieer verbeteringen

• Meet nieuwe verkeersstroom (nieuw tracerapport)

• Vergelijk voor/na-metrieken

• Documenteer wat werkte

Neem contact op met IBSurgeon bij vragen

Neem gerust contact met ons op bij vragen: [email protected].