Browser-, API- en databasetijden juist koppelen

Een traag scherm laat nog niet zien waar tijd verloren gaat. Voor gericht onderzoek moeten ontwikkeling en beheer dezelfde taak, dezelfde aanvraag en duidelijk benoemde meetgrenzen gebruiken.

Het volgende voorbeeld is volledig hypothetisch. Kenmerk req-17, alle tijden en de querystructuur zijn verzonnen. Er is geen klantsysteem gemeten.

Een concrete aanvraag afbakenen

Hier laadt een portaal een bestellijst met 20 regels. Deze veronderstelde meetwaarden horen bij de aanvraag:

Databasetijd zit in servertijd, die weer in het ophalen van de resource zit. Optellen telt inbegrepen tijd dubbel. Bij parallelle aanroepen kan de som bovendien groter zijn dan de verstreken tijd.

Absolute starttijdstippen van browser en server zijn zonder passende tijdbasis niet zomaar van elkaar af te trekken. Gebruik duidelijk afgebakende tijdsduren en een navolgbare koppeling aan dezelfde aanvraag.

Het opvallende deel nader onderzoeken

Het verzonnen proces doet 21 databaseaanroepen: een lijstquery en daarna een detailquery per regel. Dat maakt de herhaalde toegang een concreet onderzoekspunt. Alleen een hoog aantal query’s zou die structuur niet bewijzen; hier is ze expliciet deel van het voorbeeld.

Onderzoek welke informatie de weergave werkelijk nodig heeft. Een begrensde gezamenlijke ophaalactie kan een mogelijke wijziging zijn. Ze moet dezelfde toegestane records opleveren. Daaruit volgt niet dat alle gegevens in een enorme query moeten worden opgehaald.

De browserwaarde eindigt bij ontvangst van de resource. Ze bewijst niet dat het scherm dan bruikbaar is. Blijft het geblokkeerd, dan vragen verwerking, weergave en andere resources om afzonderlijk onderzoek.

Onder vergelijkbare omstandigheden toetsen

Noteer softwareversie, taak, hoeveelheid gegevens, filters en rechtenbereik. Gelijktijdige belasting en cachestatus horen erbij. Een lege en een gevulde cache kunnen verschillende uitkomsten geven.

Herhaal het proces vóór en na de wijziging onder passende omstandigheden. Controleer resultaat en toegangsgrenzen naast de tijd. Eén uitzonderlijk snelle aanvraag bewijst geen algemene verbetering.

Technische meetwaarden vragen om gecontroleerde toegang; klantinhoud is voor deze notitie niet nodig. Het onderzoek moet een onderbouwde volgende wijziging met duidelijke omvang opleveren, geen algemeen oordeel over de snelheid van de hele applicatie.

Bronnen

• MDN — Server timing

• MDN — PerformanceResourceTiming: responseEnd

• Microsoft — Chatty I/O antipattern