Aktuelt

Lesetid: 3 minutter

Dypdykk i ytelse

SOCO-gjengen har fordypet seg i ytelsestest over to fagkvelder.

Ola Kleiven har de siste årene jobbet mye med ytelse hos NRK. Med masse relevant erfaring og tidligere avholdte workshops i verktøyet k6, har han fasilitert to flotte fagkvelder om dette sentrale teamet. Det er viktig å vite hva vi ønsker å måle og hvorfor! Her er en noen av hovedpunktene.

Forutsetninger for gode målinger

Det er mange ulike typer tester som går under paraplyen ytelse eller «performance», og grunnlaget for dette er ikke nødvendigvis i tekniske krav og dyre verktøy. Det er viktig at vi vet:

  • Hva vi ønsker å måle
  • Hvor vi måler
  • Hvordan vi bør måle for best å innhente dataene vi trenger
  • Hva målingene faktisk betyr for deg eller dine brukere

Hva som måles kalles gjerne «Service Level Indicator», eller forkortet SLI. Dette er selve måledataene som du mottar fra et målepunkt, om det så er svartid, minnebruk eller noe annet. For å definere hva vi ønsker å oppnå, kan vi sette et «Service Level Objective» (SLO) – forventningene vi har til tjenestekvaliteten. Dere kan for eksempel ha en SLI som måler om applikasjonen svarer eller er nede. Da kan SLO for eksempel være en gitt feilrate på kall eller at responstiden skal være under en gitt terskel. Her kan dere velge å måle nær koden eller nær brukeren, og det er lurt å lære seg litt om persentiler og hva de egentlig innebærer.

Teamet og interessentene bør formulere slike forventninger til ytelsen før det tekniske arbeidet er kommet for langt. Dere bør også tenke gjennom hva tallene betyr. Hva innebærer det egentlig å ha «99.9% oppetid»?

Noen testtyper

Når du har et bilde av forutsetningene og behovene, er det lettere å velge mellom de mange typene ytelsestester:

  • En lasttest måler responstiden og ressursbruken ved ulike brukerbelastninger.
  • En stresstest fokuserer heller på en ekstrem og unormal belastning. Hvor stabilt er systemet vårt? Hvordan takler det eventuelle feil?
  • Beslektet med stresstest er «spiketest»; en plutselig topp på brukerbelastningen for å måle tilpasningsevnen og robustheten. Håndterer vi et sjokk i antall brukere? Kommer vi oss fort tilbake i vanlig løp?
  • Test av typisk trafikk over lengre tid. Ved å sende stor trafikk i minst ett døgn kan vi over tid måle forringelse av ytelsen – men også minne- og ressurslekasjer. Nytten ligger i å samle inn historiske data, som fort avdekker konsekvensen for ytelsen når nye endringer innføres.
  • Skalerbarhet – en kontrollert variasjon i belastning for å observere hvordan systemet håndterer variasjon over tid.
  • Det kalles volumtest når du pøser store mengder data gjennom systemet ditt og har mange samtidige transaksjoner. Håndterer vi data riktig likevel?

Hvilke verktøy bør vi bruke?

Mange er opptatt av verktøyer for ytelsestest. Ola anbefaler K6 og Gatling. Felles for dem er at de er kodefokuserte og utviklervennlige.

Er du interessert i K6? Ola har tidligere hatt workshops i K6 og mobbprogrammering, og har et ferdig opplegg klart på Github hvis du ønsker å prøve deg.

SOCO tilbyr også kurs i ytelsestest med Gatling.

Takk for to veldig lærerrike kvelder, Ola!