Een medewerker opent een klantdossier en wacht drie seconden. Het applicatieteam ziet dat een databaseaanroep lang duurt. De beheerder ziet dat de database nog CPU-capaciteit over heeft. Beide observaties kunnen kloppen. De aanvraag kan wachten op een vrije verbinding, op een vergrendelde rij of op tientallen korte queries die na elkaar worden uitgevoerd. Wie op basis van één dashboard een zwaardere databaseserver bestelt, weet nog steeds niet welke vertraging die investering moet oplossen.
Begin bij de handeling die gebruikers vertraagt
Kies één handeling die merkbaar traag is, zoals het openen van een klantdossier of het opslaan van een order. Leg vast wanneer het gebeurt, welke route de aanvraag volgt en hoe vaak het voorkomt. Kijk naast het gemiddelde ook naar de trage aanvragen. Het 95e percentiel kan bijvoorbeeld zichtbaar maken dat de wachttijd oploopt tijdens de ochtendpiek terwijl het daggemiddelde nauwelijks verandert.
Splits bij een trage aanvraag de totale responstijd uit. Hoeveel tijd kost de applicatiecode? Hoe lang wacht de aanvraag op een vrije databaseverbinding? Hoeveel tijd gaat naar SQL en hoeveel naar externe diensten? Gebruik waar mogelijk hetzelfde aanvraag-ID in traces en logs. Daarmee kun je de metingen van het applicatieteam naast die van de databasebeheerder leggen.
Kijk naar frequentie én wachttijd
Stel dat een aanvraag tachtig SQL-aanroepen achter elkaar uitvoert en dat elke aanroep gemiddeld vijftien milliseconden duurt. Samen kosten ze ongeveer 1,2 seconde. Een lijst met alleen de langzaamste losse queries kan die oorzaak gemakkelijk missen. Onderzoek in dat geval waarom de applicatie zo vaak naar de database gaat. Als een dossier per regel opnieuw dezelfde gegevens ophaalt, kan één gerichte aanpassing in de applicatie meer opleveren dan het versnellen van iedere losse query.
In MySQL laat de sys-weergave statement_analysis onder meer zien hoe vaak vergelijkbare statements worden uitgevoerd en hoeveel tijd ze samen kosten. Vergelijk de meetwaarden aan het begin en einde van het probleemvenster en gebruik de applicatietrace om te bepalen welke statements bij de trage handeling horen. In Oracle kun je naast de SQL-activiteit kijken naar wachttijden, bijvoorbeeld op I/O of vergrendelingen. Zulke databasebrede cijfers helpen het onderzoek richten. De trace laat zien welke wachttijd voor de gebruiker meetelt. MySQL Reference Manual · Oracle Database Performance Tuning Guide
Laat de meting bepalen waar je ingrijpt
- Eén query bepaalt de responstijd. Bekijk het uitvoeringsplan en hoeveel gegevens de database moet lezen. Onderzoek vervolgens of een wijziging aan de query of een index het werk terugbrengt.
- Aanvragen wachten vooral op een vrije verbinding. Meet hoe lang de applicatie verbindingen bezet houdt en controleer of transacties lang openstaan. Vergroot de pool pas als duidelijk is wat de wachtrij veroorzaakt en of de database meer gelijktijdig werk aankan.
- Meerdere processen vertragen tegelijk tijdens piekbelasting. Leg de belasting van CPU en opslag naast de wachttijden. Als een gedeelde resource aantoonbaar verzadigd raakt, wordt extra capaciteit een onderbouwde optie.
Die volgorde helpt ook bij omgevingen waarin de applicatie, database en hosting bij verschillende teams liggen. Door samen naar hetzelfde probleemvenster te kijken, kun je één ingreep kiezen en vooraf afspreken hoe je het effect meet. Dat is ook het uitgangspunt van de aanpak van Northfix voor database-optimalisatie.
Meet opnieuw wat de gebruiker merkt
Herhaal na de wijziging dezelfde handeling met vergelijkbare gegevens en belasting. Controleer de totale responstijd, de trage aanvragen en het aantal fouten of time-outs. Volg bij een nieuwe index ook de schrijftijden als dezelfde tabel veel wordt bijgewerkt. Zo zie je of een verbetering bij het openen van een dossier elders extra werk veroorzaakt.
Maak het besluit voor de volgende release concreet. Welke handeling is trager dan afgesproken, waar verdwijnt de tijd en welke meting moet na de wijziging verbeteren? Met die drie antwoorden kun je een queryaanpassing, een configuratiewijziging of extra capaciteit op dezelfde uitkomst beoordelen.
