Performance og kapacitet: måling, når SLA’en bestrides

Forside · Gennemgået oktober 2026 · Af John Nielsen

Oppetid er sjældent hele tvisten. Et system kan være oppe og alligevel så langsomt, at det ikke kan bruges, eller det kan virke fint for ti brugere og bryde sammen ved hundrede. Tvister om ydeevne handler om svartider og kapacitet, og her afhænger svaret af tre ting, der skal ligge fast, før der måles: hvad der måles, hvor det måles, og under hvilken belastning. Et gennemsnit uden de tre oplysninger kan næsten ikke bruges.

Hvordan oppetid beregnes, er beskrevet i SLA-målinger: metode og fejlkilder. Denne artikel handler om svartider, gennemløb og kapacitet, og om belastningstest som bevis.

Hvad aftalen faktisk lover

Start med aftalens ord. Krav til ydeevne formuleres meget forskelligt:

en svartid for bestemte transaktioner, fx “95 % af søgninger under 2 sekunder”
et gennemløb, fx et antal ordrer pr. time
et antal samtidige brugere, systemet skal kunne betjene
en generel formulering om “tilfredsstillende” eller “branchesædvanlig” ydeevne

Den tekniske måling skal ramme aftalens definition så præcist som muligt: samme transaktioner, samme målepunkt og samme statistik. Er aftalen uklar, bør den sagkyndige vise resultatet under de rimelige fortolkninger frem for selv at vælge én. ISO/IEC 25010 behandler ydeevne som en kvalitetskarakteristik og kan give et fælles sprog, men den erstatter ikke aftalens egne tal.

Percentiler frem for gennemsnit

Svartider er skævt fordelt: de fleste kald er hurtige, nogle få er meget langsomme. Et gennemsnit skjuler netop de langsomme kald, som brugerne klager over. Percentiler er bedre: den 95. percentil er den svartid, som 95 % af kaldene ligger under. Belastningsværktøjer bruger dem som kriterier. I k6 kan en test fx gøres betinget af, at p(95) for http_req_duration ligger under en grænse.

To forhold skal med:

Percentiler kan ikke lægges sammen. Gennemsnittet af timernes 95. percentil er ikke månedens 95. percentil. Beregningen skal laves på de enkelte målinger eller på histogrammer, der bevarer fordelingen.
Fejlede kald. Kald, der fejler hurtigt, kan trække svartiden ned. Fejlrate og svartid skal derfor opgøres sammen.

Målepunktet

Svartiden afhænger af, hvor uret står:

Serverens egne logs · Behandlingstid på serveren, uden netværk og browser
Lastbalancer eller gateway · Server plus intern trafik, uden klientens netværk
Syntetisk overvågning · Forudbestemte forløb fra et bestemt sted, med netværk
Måling i brugerens browser · Hele oplevelsen, inkl. netværk, browser og brugerens udstyr

Leverandøren måler typisk på serveren, kunden oplever i browseren. Begge kan have ret om hver sit målepunkt. Browseren kan måle tidsforløbet for en sideindlæsning via de standardiserede tidsmålinger, som W3C har beskrevet i Navigation Timing, men målingen påvirkes af brugerens egen forbindelse og computer. Om overvågningsdata og deres opbevaring, se monitoreringsdata som bevis, og om serverens adgangslogs, se webserverlogs.

Belastningstest som bevis

Når det skal afgøres, om systemet kan klare en bestemt belastning, er en kontrolleret belastningstest ofte den eneste vej. Værktøjer som Apache JMeter, k6 og Gatling kan simulere mange samtidige brugere. Testens værdi som bevis afhænger af designet:

Belastningsprofil. Hvilke transaktioner, i hvilken blanding, med hvilken tænketid mellem trinene. En profil, der kun kalder forsiden, siger intet om søgning og betaling.
Optrapning. Belastningen øges gradvist, så det kan ses, hvor svartiden begynder at stige, og hvor fejl opstår.
Testdata. Databasen skal have en realistisk størrelse. Mange problemer med ydeevne viser sig først med store datamængder.
Miljø. Testmiljøets kapacitet og konfiguration skal svare til produktion, eller forskellen skal beskrives.
Belastningsgeneratoren selv. Hvis maskinen, der genererer belastningen, er overbelastet, måler testen generatorens begrænsning og ikke systemets.

En særlig faldgrube er, at en testklient, der venter på svar, før den sender næste forespørgsel, sænker sit tempo, når systemet bliver langsomt. Testen sender så færre forespørgsler end planlagt, og de langsomste perioder bliver underrepræsenteret i resultatet. Værktøjer kan sættes op til at holde en fast ankomstrate i stedet. Testens indstilling skal fremgå af rapporten.

Flaskehalsen

At svartiden er for høj, er en konstatering. I en tvist er spørgsmålet ofte også hvorfor: er det koden, databasen, infrastrukturen eller et eksternt system? Under en belastningstest bør der derfor samtidig registreres ressourceforbrug på servere og database, ventetider på eksterne kald og fejl i applikationens logs. Traces fra APM-værktøjer kan vise, hvor tiden bruges i det enkelte kald. Årsagen kan afgøre, om problemet ligger inden for leverandørens ansvar, fx ineffektive databaseforespørgsler, eller uden for, fx et underdimensioneret driftsmiljø, som kunden selv har valgt.

Sikring af eksisterende målinger

Før der testes nyt, bør de målinger, der allerede findes, sikres:

Rådata fra overvågningen med højeste opløsning, før de aggregeres eller slettes.
Webserver- og gatewaylogs med svartidsfelter, hvis de er slået til.
Leverandørens rapporter som modtaget, sammen med beskrivelsen af, hvordan tallene er beregnet.
Kundens egne målinger, klager og skærmoptagelser med tidspunkter.
Oplysninger om belastningen i perioden: antal brugere, transaktioner og batchkørsler.

Alle eksporter hashes og registreres med kilde, metode og tidspunkt.

Dokumentation af en test

En belastningstest skal kunne gentages. Rapporten bør indeholde testscript og belastningsprofil, værktøj og version, miljøbeskrivelse med versioner og kapacitet, testdatamængde, testens tidspunkt og varighed, rå resultatfiler med hashværdi, og en beskrivelse af alle afvigelser fra plan. Begge parter bør have mulighed for at kommentere designet, før testen køres. Det er lettere at blive enige om metoden før end om resultatet efter.

Typiske fejl i fortolkningen

Et månedsgennemsnit fremlægges som bevis for, at svartiderne var i orden.
Målinger fra serveren sammenlignes direkte med brugerens oplevelse i browseren.
Perioder med planlagte batchkørsler eller backup indgår uden at blive nævnt.
En belastningstest i et mindre testmiljø bruges til at drage konklusioner om produktion.
Fejlede kald tælles som hurtige svar.
Tidszoner i overvågning og logs blandes, så spidsbelastninger placeres forkert.

Når datamængden vokser

Ydeevne er ikke konstant. Et system, der var hurtigt ved idriftsættelsen, kan blive langsomt, efterhånden som databasen vokser. I en tvist kan det derfor være relevant at vise udviklingen over tid: svartider for de samme transaktioner måned for måned, holdt op mod datamængde og antal brugere. Kurven kan skelne mellem et problem, der var der fra starten, og et, der er opstået senere.

Hvad målingerne kan og ikke kan bevise

Korrekte målinger kan vise, hvilken svartid og kapacitet systemet havde under bestemte forhold, og om det levede op til aftalens tal på det målepunkt. En belastningstest efter tvistens opståen viser systemets tilstand på testtidspunktet, ikke nødvendigvis i den periode, tvisten handler om. Den juridiske side af SLA-tvister er beskrevet på digital-bevissikring.dk, og kundens egen dokumentation på bevissikring-digitalt.dk.

Kilder og versioner

Senest gennemgået: oktober 2026.

Næste skridt

Læs også: CI/CD-logs og deployment-historik som bevis · Kildekodegennemgang: metode, omfang og dokumentation

→ Uvildig IT-sagkyndig med forensic-baggrund · For IT-afdelingen · Tlf. 70 13 63 23 · Digital bevissikring hos Nielco IT

Skrevet af John Nielsen, IT‑sagkyndig og indehaver af Nielco IT. Selvstændig siden 2009 og mere end 30 års erfaring med IT‑sikkerhed. Har været IT‑sagkyndig i danske retskredse og ved Den Fælles Europæiske Patentdomstol (UPC). Om John Nielsen · LinkedIn · Redaktionel politik

Brug for en forensisk undersøgelse?

Skriv kort, hvilke systemer eller enheder det drejer sig om, og om noget haster, så vender jeg tilbage. Kun civile sager.

Eller kontakt os på