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

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

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

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

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

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.