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.
En performancetest er en samling af tests der udføres for at undersøge skalerbarheden af et system samt hvorledes dette opfører sig i pressede situationer. |
En ramp-up-test (stress-test, breakpoint-test eller capacity-test) er en performancetest der sigter efter at finde et systems maksimale ydeevne samt identificere hvilke fejl der opstår i systemet under disse forhold. Testen øger belastningen af systemet i flere iterationer og måler både svartiden og kapaciteten. Dette er den primære performancetest der kræves på NSP for at idræftsætte en komponent. |
En endurance-test er en performancetest der undersøger hvorledes et system opfører sig under kontinuerlig høj belastning. Testen bruges ofte for at undersøge systemet for "memory leaks" mv. |
En spike-test er en performancetest der undersøger hvorledes et system opfører sig under spidsbelastninger, højere end dem systemet kan forvente under normal drift. |
Baggrundsdata er data der ligger i en database eller andet storage-system inden performancetest går i gang. |
Testdata er de data der genereres under en performancetest og/eller anvendes som input til en performancetest. |
I dette dokument anvendes "Testplan" synonymt med "JMeter Test Plan". Der er ikke tale om en samlet testplan for testen af en komponent, blot den JMeter fil der beskriver hvorledes komponenten kaldes under en performancetest. |
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 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:
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).
Sundhedsdatastyrelsen kan ligeledes stille krav til yderligere performancetest i de udbud/kravspecifikationer som ligger bag et udviklingsprojekt. Disse performancekrav kan være følgende:
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.
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.
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.
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.
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.
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
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:
Under en performancetest opsamles de logfiler som komponenten producere samt følgende målinger:
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.