Dette dokument beskriver udvikling og afvikling af jmeter tests.
Version | Dato | Ansvarlig | Beskrivelse |
1.0 | 15-11-2018 | Openminds | Oprettelse |
| 1.1 | 14-11-2019 | Lakeside | Opdatering vedr. test krav |
| 1.2 | 24-09-2020 | KvalitetsIT | Opdatering ifm. flytning af test til arosiis performance test framework |
Det følgende beskriver performance test og analyse for
Først i dette afsnit beskrives de forskellige typer test data output, og hvordan de anvendes i analysen. Herefter skitseres scope og afvikling af testene samt performance kravene.
Se iøvrigt krav til performance test og rapport på siden https://www.nspop.dk/display/public/web/Performancekrav
For alle test gælder følgende:
Udover de fremsatte performance krav på svartid, er der en række andre punkter, som bør analyseres for at vurdere servicens sundhed.
Følgende punkter undersøges derfor:
Disse undersøgelser foretages vha. de forskellige log filer, som genereres under performance testen. De følgende afsnit gennemgår de vigtigste tal fra disse filer:
Hver kørsel/iteration (øgning af belastning) har en start og slut tid. Filerne access.log og jstat.log indeholder tidstempler. Dette muliggør at de kan mappes til en given iteration. Filen vmstat har ikke tidstempel. Men da den starter samtidig med jstat loggen og logintervallet er kendt på 10 sekunder, kan iterationernes placering i data beregnes. Docker stats loggen har hverken tidsstempel eller fast logninginterval, hvorfor tallene/graferne kun kan bruges som en generel betragtning over hele test perioden.
I det nedenstående kan man klikke på de enkelte grafer for større billede. De enkelte iterationer er tegnet ind som lodrette mørke streger; 2 streger per iteration (start og slut tidspunkt).
Testene involverer følgende komponenter
Versionen af MinLog2 og test frameworket varierer for hver test og fremgår nedenfor.
MinLog 2's overordnede arkitektur ses af følgende figur (kilde: arkitektur dokumentet)
Lookup/forespørgsler test vedrører kun "lookup" komponenten, da der ingen opdateringer (registration ) foregår imens, og der dermed heller ingen aktivitet er på "consumer" komponenten. Dette betyder konkret, at de tilsendte log filer, som vedrører "consumer" komponenten ikke analyseres for lookup rapporterne.
Registration består af 2 komponenter: registration komponenten, som modtager input og gemmer data ned i sin "lokale" kafka. Data herfra flyttes af mirrorMaker over på den centrale kafka i backoffice. Og den anden komponent kafka-consumer, der tager fra den centrale kafka og flytter data i databasen.
Der er ikke målinger på database serveren (MariaDB).
MinLog2 - Performancetest minlog1 lookup
MinLog2 - Performancetest medhjælper lookup
MinLog2 - Performancetest borger lookup
MinLog2 - Performancetest registration
Performance testen afvikles på følgende måde
Se iøvrigt MinLog 2 test performancetestvejledning for detaljer.
Servicemålene herunder er for henholdsvis MinLog 2 registreringsservices (svartider opdatering) og MinLog opslagsservices (Svartider forespørgsler).
| Service | Servicemål |
|---|---|
| Svartider opdatering | 95 % af tilfældene ≤ 6,5 sek |
| 98 % af tilfældene ≤ 15,5 sek | |
Svartider forespørgsler | 95 % af tilfældene ≤ 2,5 sek |
| 98 % af tilfældene ≤ 5,5 sek |
Både MinLog2 og Minlog1 bør testes, da alle snitflader vil blive belastet i indkøringsfasen, det forudsættes at de eksisterende MinLog1 performances test kan benyttes.
Borger
Der skal udarbejdes et CPR nummer SELECT repræsenterende forskellige grupper i forhold til mængder af MinLog logninger i alt svarende til 2 % af alle med MinLog borger entrys.
| Interval af antal entrys | Antal CPR numre |
|---|---|
| 0 - 50 | 20.000 |
| 50 - 100 | 20.000 |
| 100 - 500 | 20.000 |
| 500 - 1000 | 20.000 |
| 1000 - 5000 | 19.000 |
| 5000 -10.000 (hvis de findes?) | 1.000 |
Sundhedsfaglig - Medhjælpslog
Der skal udarbejdes et CPR nummer SELECT af nedre og øvre kvartil i mængden af MinLog logninger svarende til 2 % af alle med MinLog medhjælps entrys. CPR nummerne skal være sundhedsfaglige med delegering.
Der skal udarbejdes et registration sæt som indsættes med 20.000 registringer pr. 5 min interval stigende op mod 60.000 pr. 5 min. interval.
Der skal teste både bulk og single registreringer.
Databasen skal indeholde en kopi af produktion.
Til lookup Id ws anvendes følgende fil:
Til lookup Id on behalf of anvendes følgende fil:
Til registration anvendes følgende fil
Antal registreringer pr. kald kan konfigureres
Testen hentes fra https://svn.nspop.dk/svn/components/performance/trunk i den revision, der er angivet nedenfor per release af MinLog 2 servicen.
Databasen klargøres.
Der skal være en kørende version af MinLog 2 servicen, man kan teste imod. Og host.properties skal være sat korrekt op jf. arosiis performance test framework.
Når databasen er på plads, servicen kørende og testen configureret kan følgende køres:
run_test.sh -h hosts.properties -p 9012 minlog listlogstatements test900
run_test.sh -h hosts.properties -p 9012 minlog2 lookup_onbehalfof test900
run_test.sh -h hosts.properties -p 9012 minlog2 lookupidws test900
run_test.sh -h hosts.properties -p 9012 minlog2 registration test900
(distributionenerne *test900 kører 15 minutter, der findes også kørsler til 10 sekunder (*test10) )
MinLog2 Release | Performance test revision |
|---|---|
| 2.*.* | 2.0.* |
'* ' betyder hvilken som helst
Der er lavet en LookupRequestSampler. Den tager et cpr som input og forventer der er et IDCard på threadcontexten. Med inputtet laver den et kald til GetLogStatementsForCPRPerson. Vær opmærksom på at testen er bundet til et certifikat og dermed et idcard og dermed et lookup.
Se eksemplet her.
.../tests/minlog2/src/test/jmeter/templates/testplans/lookup.template.jmx
Her laves der lookup on behalf of hvor man enten benytter et medarbejder certifikat eller et firmacertifikat.
I setup fasen indhentes certifikatet og herefter startes selve performance testen.
Lookup on behalf of sampleren tager et cpr som input. Så det er muligt at sætte testen op så man indlæser en fil med flere cprnumre og bruger forskellige hver gang et kald laves.
Vi har lavet et eksempel på hvordan det kan sættes op her.
.../tests/minlog2/src/test/jmeter/templates/testplans/lookup_onbehalfof.template.jmx
Under setup hentes der nemind certifikater for de test brugere der benyttes. Lookupidentitytoken sampleren tager cpr, procurator cpr og subject som input. De nemid certifikater der hentes ind gemmes i et statisk map så de kan genbruges af lookupid sampleren i selve performance testen.
Lookupidws sampleren tager et cpr som input. Den bruger cpr til at hente certifikatet fra setup af og laver hefterter et kald til minlog2 hvor certifikatet benyttes.
Vi har lavet et eksempel på hvordan det kan sættes op her.
.../tests/minlog2/src/test/jmeter/templates/testplans/lookupidws.template.jmx
Vi har lavet et eksempel på hvordan det kan sættes op her.
tests/minlog2/src/test/jmeter/templates/testplans/registration.template.jmx