Knytt nettleser-, API- og databasetider riktig sammen

En treg skjerm viser ikke hvor tiden går tapt. En målrettet undersøkelse krever at utvikling og drift bruker samme oppgave, samme forespørsel og tydelig beskrevne målegrenser.

Følgende eksempel er helt hypotetisk. Identifikatoren req-17, alle tider og spørringsstrukturen er oppdiktet. Ingen kundesystemer er målt.

Avgrens en konkret forespørsel

Her laster en portal en bestillingsliste med 20 rader. Disse antatte målingene tilhører forespørselen:

Databasetiden inngår i servertiden, som igjen inngår i hentingen. Å legge dem sammen teller samme tid flere ganger. Ved parallelle kall kan summen også overstige den forløpte tiden.

Nettleserens og serverens absolutte starttidspunkter kan ikke bare trekkes fra hverandre uten et passende tidsgrunnlag. Bruk definerte varigheter og en sporbar tilknytning til samme forespørsel.

Undersøk delen som skiller seg ut

Det oppdiktede forløpet gir 21 databasekall: en listespørring og deretter en detaljspørring per rad. Den gjentatte tilgangen blir dermed et konkret undersøkelsespunkt. Et høyt antall alene ville ikke bevist strukturen; her er den eksplisitt del av eksemplet.

Undersøk hvilken informasjon visningen faktisk trenger. En avgrenset samlet henting kan være en mulig endring. Den må levere de samme tillatte postene. Det følger ikke at alle data bør hentes i én enorm spørring.

Nettlesertiden slutter når ressursen er mottatt. Den beviser ikke at visningen da er brukbar. Er den fortsatt blokkert, må behandling, gjengivelse og andre ressurser undersøkes separat.

Test under sammenlignbare forhold

Noter programvareversjon, oppgave, datamengde, filtre og rettighetsområde. Samtidig belastning og tilstanden til cachen hører også med. En tom og en fylt cache kan gi ulike resultater.

Gjenta forløpet før og etter endringen under passende forhold. Kontroller resultat og tilgangsgrenser sammen med tiden. Ett særlig raskt kall beviser ingen generell forbedring.

Tilgang til tekniske målinger bør styres; kundeinnhold trengs ikke til dette notatet. Undersøkelsen skal gi en begrunnet neste endring med tydelig omfang, ikke en generell dom over hele applikasjonens hastighet.

Kilder

• MDN — Server timing

• MDN — PerformanceResourceTiming: responseEnd

• Microsoft — Chatty I/O antipattern