Leverancen indeholder unit tests, integrationstest og performance/endurancetests.
Unittests bør afvikles som en del af byggeprocessen, mens integrationstesten bør afvikles mod den deployede komponent. Begge disse tests kan afvikles med maven.
Endurancetesten bør afvikles med jmeter mod den deployede komponent.
Indeværende dokument et sammendrag af dokumentet MinLog2-Testvejledning og performance
Læseren forventes at have kendskab til National Sundheds-IT's platform NSP, samt generelt kendskab til WildFly applikation server, MariaDB, Kafka og java.
Version | Dato | Ansvarlig | Beskrivelse |
1.0 | 10-10-2019 | Openminds |
Definition | Beskrivelse |
NSP | Den nationale service platform (inden for sundheds-IT) |
Unit tests bliver afviklet som en del af bygget, med mindre man eksplicit angivet, at det ikke ønskes.
Kør 'mvn clean install' eller 'mvn clean test'
Cobertura benyttes til – via maven – at danne en coverage rapport:
|
Rapporten kan også findes i code/target/staging.
Det er et krav, at der skal være en coverage på 80 %. Dog kan fx genereret kode afvige fra dette.
Nedenfor er beskrevet, hvilke pakker, der vurderes ikke at leve op til coverage kravet.
Følgende pakker indeholder genereret kode eller 3. part:
Derudover kode uden forretningslogik
Det følgende beskriver performance test og analyse for
Først beskrives de forskellige typer test data output, og hvordan de anvendes i analysen. Herefter skitseres scope og afvikling af testene samt performance kravene. Og endelig analyseres data for hver enkelt test.
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 det fremsatte performance krav på svartid, er der en række andre punkter som bør analyseres for at vurdere servicens sundhed.
Følgende punkter bliver derfor undersøgt:
Der er ikke målinger på database serveren (MariaDB) eller Kafka serveren.
Undersøgelserne foregår vha. de forskellige log filer, som er genereret 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 er startet 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årimens, og der dermed heller ingen aktivitet er på "consumer" komponenten. Dette betyder konkret, at de vedlagte log filer, som vedrører "consumer" komponenten ikke analyseres.
Performance testen er afviklet på følgende måde
Se iøvrigt MinLog 2 test performancetestvejledning for detaljer.
Performance krav til MinLog 2 Performance test er som følger:
| 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 |
Performance testen består af en række kald til opslag efter logninger på forskellige cpr numre. Et sådant enkelt opslag vil svare til, hvad en borger vil udføre, skulle han ville se hvad der er registreret om ham.
Testen udført er komponent "minlog2", testplan "lookupidws" og distribution "test900".
MinLog 2 service er version 2.0.25perf og NSP standard performance test framework version 2.0.21.
De rå test resultater er vedhæftet denne side (TODO)
JMeter hoved filen beskriver overordnet testens resultat. Her kan kan ses, at der er kørt 10 iterationer med test, deres tidsinterval , throughput og fejlprocent for hver.
Iteration | Tråde | Nodes | Starttid | Sluttid | Throughput | Fejlprocent |
|---|---|---|---|---|---|---|
| 1 | 1 | 2 | 2020-03-12_10-02-36 | 2020-03-12_10-17-40 | 3,26 kald per sekund | 0 % |
| 2 | 2 | 2 | 2020-03-12_10-17-57 | 2020-03-12_10-33-00 | 5,89 kald per sekund | 0 % |
3 | 3 | 2 | 2020-03-12_10-33-19 | 2020-03-12_10-48-23 | 8,6 kald per sekund | 0 % |
| 4 | 4 | 2 | 2020-03-12_10-48-40 | 2020-03-12_11-03-45 | 10,89 kald per sekund | 0 % |
| 5 | 5 | 2 | 2020-03-12_11-04-01 | 2020-03-12_11-19-05 | 12,91 kald per sekund | 0 % |
| 6 | 6 | 2 | 2020-03-12_11-19-22 | 2020-03-12_11-34-27 | 14,42 kald per sekund | 0 % |
| 7 | 6 | 3 | 2020-03-12_11-34-47 | 2020-03-12_11-49-50 | 20,82 kald per sekund | 0 % |
| 8 | 6 | 4 | 2020-03-12_11-50-26 | 2020-03-12_12-05-39 | 26,93 kald per sekund | 0 % |
| 9 | 6 | 5 | 2020-03-12_12-06-40 | 2020-03-12_12-21-43 | 34,04 kald per sekund | 0,008 % |
| 10 | 6 | 6 | 2020-03-12_12-22-36 | 2020-03-12_12-37-41 | 37,12 kald per sekund | 0 % |
Det fremgår også af filen, at den endelige måling af throughput er 37,12 kald per sekund.
Samt at fejlprocentet på den fulde kørsel er 0 %.
Denne log findes for hver applikations server (docker container).
Her findes data for hvert enkelt kald, der er lavet til minlog servicen, herunder hvor lang tid et kald har taget (Duration) samt hvornår kaldet er udført. Ud fra loggens data kan man også beregne hvor mange kald der udføres i en given periode.
De følgende 2 grafer viser 95 % hendholdsvis 98 % percentil for kaldende. Grupperingen er 10 minutter:
Den næste graf viser antal kald per sekund:
TODO
Denne log findes for hver applikations server (docker container). Den viser resultatet af kommandoen vmstat
Udtræk omkring cpu fra denne log vises i de følgende grafer:
Data serier i grafen er:
Man kan se at cpuIdle og cpuNonKernel påvirkes lidt som servicen presses mere. cpuIdle ligger lavere over tid, mens cpuNonKernel grafen ligger en smule højere over tid. Den generelle flyt af kurverne er dog ikke faretruende.
Man kan også se, at cpuIdle dykker til 0 nogle få gange hen over iterationerne. Når dette sker er der en stigning i cpuKernal. Udsvingende vender dog retur til udgangspunktet.
Udtræk omkring io læs og skriv fra vmstat vises i de følgende grafer:
Data serier i grafen er:
Der er lidt løbende skriv til disken mens testen kører, og sammenligner man graferne fra før på cpu forbrug, ses det, at de få store udsving i skrivninger falder sammen med at cpuKernal går op og cpuIdle går ned.
TODO
TODO