You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 3 Next »

Noter fra SDS

-          Hvem er læseren af dette afsnit?

-          Der mangler definitioner af en række begreber i teksten, herunder endurance-test, ramp-up stress test, spike test mm. - Lav en detaljeret faktaboks. perftest er en gruppe af tests

-          Det bør præciseres hvilke operationer der skal performancetestes i en service – alle?, læs?, skriv? - Alle med mindre andet aftales, behovet bør vurderes.

-          Er performance test det samme som en ramp-up/stress  test? - perftest er en gruppe af tests

-          Der mangler noget overordnet om test setup’et, herunder infrastruktur, og testdata - testdata skal hænge sammen på tværs af komponenter. Infrastruktur er en kopi af produktion

-          Det er ikke kun svartider der er afgørende. Det skal sikres at servicen ikke fejler ved kald. - Tilføj assertion.

-          En testplan indeholder mere end opskriften på hvordan testen skal udføres. - Med testplan menes den JMeter fil, ikke den store samlede testplan for projektet.

+ Nævn OAT processen og hvad der sker hvornår. Miljø afklares også på OAT

+ Beskriv den vmstat mv. der laves.

Indledning

Alle komponenter der skal køre på NSP skal igennem en performancetest der som minimum skal belyse hvor mange forespørgelser per sekund komponenten kan håndtere og hvad den forventede svartid er ved forskellige belastninger. Yderligere performance tests kan være stillet som krav i det udbud eller den kravspecifikation som et projekt arbejder med.

Formålet med performancetesten er at give NSP Driften en mulighed for at overvåge belastningen af komponenten og reagere inden dens maksimum er nået. Ligeledes kan svartiden overvåges for at sikre at slutbrugerne får den forventede oplevelse.

Krav

Der stilles krav til performancetesten både af NSP som modtager af komponenten og af projektet som kunde ifm udviklingen af nye komponenter eller større refactoreringer. I det følgende gennemgåes disse krav

NSP

NSP stiller som krav at der er kørt en ramp-up/stress test der retvisende redegør for svartider og throughput ved forskellige stigende belastninger af komponenten. Dette kan deles op i følgende underkrav:

  • Der skal foretages kald af alle komponentens forskellige funktioner der matcher det forventede virkelige brugs-scenarie.
    • Antallet af kald til hver funktion skal ske ud fra en redegørelse over det forventede brug
    • Input til funktionerne skal være ligeligt fordelt over et stort nok udfaldsrum til at sikre at svartiderne ikke bliver kunstigt lave grundet en "varm" cache mv.
    • Baggrundsdata skal være realistiske i både mængde og diversitet.
  • Hver iteration af testen skal vare længe nok til at kunne give realistiske gennemsnitlige svartider
  • Belastningen skal øges for hver iteration af testen.

Projekt

Sundhedsdatastyrelsen kan ligeledes stille krav til yderligere performancetest i de udbud/kravspecifikationer som ligger bag et udviklingsprojekt. Disse performancekrav kan være følgende:

  • En Endurance test der viser at komponenten ikke "sander til" over tid.
  • En Spike test der viser at komponenten kan håndtere udsving i belastningen.

NSP Performance Framework

Alle performancetests skal udvikles i og afvikles med NSP Performance Framework. Dette sikrer en ensartet struktur og en fælles forståelse for genbrugeligheden af de performancetests der udvikles. Frameworket har stort fokus på at en performancetest skal være så "self-contained" som muligt for derved at sikre at den kan genkøres med minimal manuel indblanding.

Apache JMeter

NSP Performance Framework bygger på Apache JMeter version 2.9 og JMeter Maven Plugin version 1.8.0. Frameworket består af udvidelser af JMeter funktionaliteten til håndtering af id-kort og kald af DGWS services.

Komponentspecifikke udvidelser

Udvikling af en performancetest sker ved at der laves udvidelser af de klasser som frameworket indeholder. Udvidelserne laves således at de kan kalde de enkelte funktioner der findes i komponenten.

Testplan vs Distribution

NSP Performance Framework skilner mellem en testplan og en distribution. En testplan indeholder opskriften på hvilke funktioner i komponenten der skal kaldes og i hvilken rækkefølge dette kan ske. En distribution indeholder værdier der styrer hvor ofte/mange gange hver enkelt funktion kaldes pr. iteration. Hvis en komponent f.eks. forventes at have et kaldsmønster når brugerne møder ind og et andet midt på dagen (f.eks. grundet ekstra mange logins om morgenen) så modeleres dette med en enkelt testplan men med to distributioner.

Øget belastning

En JMeter testplan har et fast antal tråde der kalder komponenten og en veldefineret løbetid som en iteration tager. For at kunne øge belastningen langsomt samt kører testen fra flere samtidige noder indeholder NSP Performance Framework et programmel der synkronisere afvikling på flere noder og øger antallet af tråde mellem hver iteration. Programmet sørger også for at angive hvilken host komponenten kan kaldes på og står for opsamling af logs.

Roller

I forbindelse med en performancetest findes der en et antal aktører der har forskellige roller undervejs. I det følgende gennemgåes hver rolle og dens aktioner

Komponentleverandør

  • Får skrive adgang til et "JMeter Extension modul" og et "testplaner & distributioner modul" i det delte projekt NSP Performance Framework.
  • I JMeter modulet udvikles udvidelser til frameworket der er i stand til at kalde funktionerne i komponenten.
  • I test modulet udvikles testplaner og distributioner i sammenhæng med de analyser af det forventede virkelige brugs-scenarie.
  • Afvikler performancetesten på en lokal maskine (flere klientnoder kan simuleres på en enkelt maskine)
  • Levere en testvejledning der beskriver de forskellige testplaner og distributioner og hvorledes disse skal afvikles
  • Forfatter en performancetestrapport på baggrund af de logs der udleveres efter kørsel af performancetesten

Kvalitetssikring

  • Præsentere NSP Performance Framework for komponentleverandøren og gennemgår ideerne bag.
  • Understøtter udviklingen af performancetesten gennem løbende QA.
  • Vedligeholder de fælles funktionaliteter der findes i frameworket
  • Modtager og kvalitetssikrer performancetesten og testvejledningen.
  • Guider driftleverandøren igennem afvikling af performancetesten

Drift

  • Vedligeholder klientmaskiner og Staging miljø
  • Udfører performancetesten
  • Opsamler logfiler til rapporten.

Projekt

  • Gennemgår performancerapporten.

Rapport

Når en performancetest er afviklet skal der produceres en performancetestrapport. Denne skal redegøre for hvilke testplaner/distributioner der har været afviklet og skal præsentere findings ifm hver test. Følgende indhold forventes som minimum i en performancerapport:

  • Det maksimale Throughput målt under testen og hvorledes dette forholder sig til det forventede brug.
  • Gennemsnitlig svartid (100% og 95% fraktil) for de forskellige iterationer samt hvilket Throughput der skabte denne svartid.
  • Bevist for at svartidskravene i kravspecifikationen er overholdt.
  • Grafer over Throughput, Gennemsnitlig svartid, CPU belastning, Heap forbrug, IO wait time.
  • En analyse af hvad der er den begrænsende faktor for Throughput og svartid.
  • Foreslag til hvorledes Throughput kan øges og svartid kan mindskes baseret på de observationer der er foretaget.
  • No labels