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.

Udvikling, kvalitetssikring, afvikling og alle andre aspekter af en performancetest afklares ifm OAT processen. Det er i denne process at eventuelle afvigelser skal aftales og den samlede plan for performancetesten skal lægges. I denne process indgår alle deltagene parter. Arbejdet med en performancetest påbegyndes på det første OAT møde.

Definitioner

Krav

Der kan stilles krav til performancetesten både af NSP som modtager af komponenten og af fra to sider til hvilke performancetests der skal køres af en komponent der skal idriftsættes på NSP. SDS-projektet som kunde, ifm udviklingen af nye komponenter eller større refactoreringer, stiller krav gennem kravspecifikationen. NSP, som modtager af komponenten og ansvarshavende for driften af denne, stiller krav gennem dette dokument. I det følgende gennemgåes disse krav

...

• 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.
  • Testdata skal hænge sammen på tværs af alle komponenter.
  • Testen skal undersøge at komponenten svarer som forventet og uden fejl.
• Hver iteration af testen skal vare længe nok til at kunne give realistiske gennemsnitlige svartider
• Belastningen skal øges for hver iteration af testen.

Vær opmærksom på at alle operationer/funktioner som en komponent udstiller skal performancetestes. Hvis det vurderes at en funktion ikke giver mening at teste (f.eks. grundet meget lav brugsfrekvens) skal det aftales ifm OAT processen om denne funktion kan udelades.

I forhold til baggrundsdata og testdata er det et krav at disse er representativt (mængde og fordeling) på tværs af alle de komponenter som vil indgå i en performancetest. Dvs hvis en ny komponent kalder en eksisterende komponent skal data være relevant og repræsentativt for begge komponenter (Hvis f.eks. MinSpærring kaldes skal der være baggrundsdata der matcher de CPR numre der anvendes som testdata).

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:

• At komponenten overholder visse svartidskrav under en bestemt belastning.
• 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.

...

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. Ligeledes laves der JMeter Assertions der verificerer at komponenten svarer som forventet.

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.

...

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.

Staging miljø

Alle performancetests udføres på NSP's Staging miljø. Miljøet består af 2 applikationsnoder, en loadbalancher samt et database cluster og et Kafka cluster. Miljøet er hardwaremæssigt identisk med produktion. Hvis komponenten har særlige miljø-mæssige krav skal disse afklares i OAT processen. Staging miljøet kan indeholde kopier af produktionsdata og der gives derfor ikke direkte adgang til miljøet. Dette betyder at selve afviklingen af en performancetest udføres af driften.

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

...

• 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.

Logs og målinger

Under en performancetest opsamles de logfiler som komponenten producere samt følgende målinger:

• vmstat - Opsamler målinger af virtuel memory-forbrug på process niveau.
• dockerstat - Opsamler målinger af resource-forbrug for en Docker process.
• jstat - Opsamlinger målinger af f.eks. Garbage Collection i en Java process.
• iostat - Opsamlinger målinger af io-forbrug (f.eks. disk) på et system.

Alle disse logfiler og målinger samles med de logfiler som NSP Performance Framework producerer og udleveres til komponentleverandøren, så denne kan producere grafer mv. til performancetestrapporten.