Performancetesten består af et antal kald til læsning af allergier for en liste af 50.000 personer (cpr numre).
Testen involverer følgende komponenter
Kravene fra fra kravspecifikationen lyder som følger:
Kommentarer til krav og forudsætninger:
Performance testen er afviklet på følgende måde
Se iøvrigt LAR test vejledning afsnit 2.3 performance test for detaljer.
De rå test resultater er vedhæftet denne side (lar-cave-perftest.tgz)
Udover det fremsatte performance krav med en svartid på under 200 ms, er der en række andre punkter som bør analyseres for at vurdere servicens sundhed.
Følgende punkter bliver derfor undersøgt:
Da hverken LAR eller CAVE servicen skriver til disk selv, bliver io til disk ikke undersøgt. Der er ikke målinger på database 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.
Hvor der i nedenstående er grupper af 4 grafer, skal de læses fra venstre mod højre og ned og mod højre: dette viser app server 1, 2, 3 og 4. Klik på den enkelt graf for større billede. De enkelte iterationer er tegnet ind som lodrette mørke streger; 8 streger, der sympolisere de 3 iterationers start og slut tidspunkt.
JMeter hoved filen beskriver overordnet testens resultet.
Her kan kan ses, at der er kørt 3 iterationer med test, deres tidsinterval og throughput for hver.
Iteration | Tråde | Nodes | Starttid | Sluttid | Throughput |
---|---|---|---|---|---|
1 | 7 | 2 | 2019-05-13_11-10-14 | 2019-05-13_11-25-18 | 20,42 kald per sekund |
2 | 10 | 2 | 2019-05-13_11-25-41 | 2019-05-13_11-40-44 | 20,84 kald per sekund |
3 | 10 | 3 | 2019-05-13_11-41-12 | 2019-05-13_11-56-17 | 25,09 kald per sekund |
Det fremgår også af filen, at den endelige måling af throughput er 25,09 kald per sekund.
Samt at fejlprocentet på den fulde kørsel er 0,01 %.
Kravet til testen er, at der skal køres med 10 samtidige brugere med hver et kald per sekund. NSP's test framework fungerer med en bestemt belastning i testen som gradvis øges. I første iteration har testen kørt med 20 kald per sekund, hvilket ligger over kravet til testen. Da testen også har kørt med MSB servicene aktiveret, hvilket ikke er et krav, har det lagt yderligere pres på testen.
Derfor konkluderes det, at ud fra JMeter loggens data, er performance kravets forudsætning om 10 brugere med hver et kald per sekund så rigeligt overholdt.
Denne log findes for hver applikations server (docker container) for både LAR og CAVE servicen.
Her findes data for hvert enkelt kald, der er lavet til de 2 LAR og CAVE services, herunder hvor lang tid et kald har taget (Duration). Ved at kigge på de kald, der er foretaget til LAR servicen kan den gennemsnitlige tid et kald tager beregnes.
Desuden kan tidsforbruget for kald til MSB servicene findes via via servicenes sla logs (nsputil-sla-lar.log) og messageid, og på den måde trækkes fra LAR servicens tid for at få netto tiden per kald.
Følgende tabel viser en række beregnede data fra access loggen fordelt på applikations server (container), test iteration og http kode. Nederst i tabellen er tallene for hver applikations server lagt sammen. Test iteration er beregnet ved at sammenligne tidstempel fra access log med start og sluttidspunktet for iterationen. Http koden findes i access loggen (kald returnerede med fejl (500) eller ingen fejl(200)).
De beregnede data er antal kald, kald per sekund i gennemsnit (hver iteration er 900 sekunder) samt tidsforbrug per kald i millisekunder.
Applikations server | Iteration | HttpCode svar | Antal kald | Kald per sekund | Tidsforbrug (ms) | |
---|---|---|---|---|---|---|
Med MSB | Uden MSB | |||||
docker01.cnsp.stage.nsp.netic.dk-lar | 1 | 200 | 4597 | 5,1 | 623 | 154 |
2 | 200 | 4693 | 5,2 | 868 | 177 | |
3 | 200 | 5650 | 6,3 | 1123 | 206 | |
500 | 1 | 0 | 32257 | 32189 | ||
docker02.cnsp.stage.nsp.netic.dk-lar | 1 | 200 | 4597 | 5,1 | 612 | 149 |
2 | 200 | 4693 | 5,2 | 900 | 193 | |
3 | 200 | 5650 | 6,3 | 1125 | 197 | |
500 | 1 | 0 | 31634 | 31579 | ||
docker03.cnsp.stage.nsp.netic.dk-lar | 1 | 200 | 4598 | 5,1 | 620 | 153 |
2 | 200 | 4693 | 5,2 | 885 | 173 | |
3 | 200 | 5650 | 6,3 | 1114 | 185 | |
500 | 1 | 0 | 33109 | 32917 | ||
docker04.cnsp.stage.nsp.netic.dk-lar | 1 | 200 | 4598 | 5,1 | 624 | 162 |
2 | 200 | 4692 | 5,2 | 904 | 192 | |
3 | 200 | 5652 | 6,3 | 1124 | 197 | |
Total | 59766 | 896 | 181 | |||
Total for alle 4 servere | 1 | 200 | 18390 | 20,4 | 620 | 155 |
2 | 200 | 18771 | 20,9 | 889 | 184 | |
3 | 200 | 22602 | 25,1 | 1122 | 196 | |
3 | 500 | 3 | 0 | 32333 | 32228 | |
Udtræk af svartid og antal kald fordelt over testens løbetid vises i følgende 4 grafer. Svartiderne er uden MSB tidsforbruget:
Data serier i grafen er:
Af tabel og grafer fremgår det, at jo flere nodes og tråde (disse øges per iteration) jo flere kald kommer der igennem per sekund. Tallene svarer overens med de tal JMeter kom frem til som throughput.
Det ses (tydligst i tabellen), at jo flere nodes/tråde jo højere bliver svar tiden. Performance kravet er 200 ms ved 10 brugere uden MSB services slået til. Ovenstående tabel viser, at ved iteration 1 er svartiden 155 ms, og tidligere fremgik det at througput her var 20 kald per sekund. Vi er inden for performance kravet.
Man kan undres over, hvorfor det skal tages så meget mere tid når MSB servicene medtages. Det har vist sig at kaldet til BRS er lavet uhensigtmæssigt, hvilket bliver rettet på Jira CAVE-78.
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 4 grafer.
Data serier i grafen er:
De 4 dataserier i graferne er meget stabile. Man ser en aktivitet omkring start og slut af de 3 iterationer. Størst udsving er der ved opstart af testen, hvor den cpu der bliver brugt af applikationen (cpuNonKernel) stiger meget og idle cpu tilsvarende falder. Men det er kun kortvarigt.
Der er intet negativt at bemærke omkring cpu forbruget.
Denne log findes for hver applikations server (docker container) - en for LAR og en for CAVE. Loggen viser resultatet af kommandoen jstat. Jstat siger noget om, hvordan JVM'en har det.
Udtræk omkring hukommelse og garbage collection fra denne log vises i de følgende 4 grafer for henholdsvis LAR og CAVE.
LAR servicen:
CAVE servicen:
Data serier i grafen er:
Det kan være lidt svært at se ændringer i graferne for full garbage collection (FGC). Kigger man nærmere på datagrundlaget bag graferne, ses det, at der er kørt full garbage collection for LAR servicen i testens 1. minut (8. loglinie - i starten af iteration 1) og i testens 41. minut (420. loglinie - midt i 3. iteration).
For CAVE kan man se, at der ikke er kørt fuld garbage collection. Der køres også oftere garbage collection på den yngre hukommelse på LAR servicen end der gør på CAVE.
Den brugte yngre hukommelse svinger noget for både LAR og CAVE, men dog i et konstant interval.
Den yngre forbrugte hukommelse eskalerer ikke for hverken LAR eller CAVE. Garbage collecteren gør sit arbejde.
Denne log findes for hver applikations server (docker container) - en for LAR og en for CAVE. Loggen viser resultatet af kommandoen docker stats. Docker stats siger noget om, hvordan containeren forbruger sine ressourcer.
Udtræk omkring hukommelse, cpu netværkstrafik vises i følgende 3 * 4 grafer.
LAR service - Hukommelse:
CAVE service - Hukommelse:
Data serier i grafen er:
Den forbrugte hukommelse for CAVE servicen er meget stabil. For LAR servicen er den svagt stigende, men da jstat statistikken ikke indikerer at selve applikationen øger forbruget af hukommelse, anses det ikke som et problem.
LAR service - Cpu og hukommelse procent:
CAVE service - Cpu og hukommelse procent:
Data serier i grafen er:
Begge procenter er stabil for CAVE servicen. LAR servicen viser et stigende forbrug af hukommelse, men som skrevet for forrige graf anses det ikke som et problem.
LAR service - netværk:
CAVE service - Netværk:
Data serier i grafen er:
De 2 grafer for ind- og udsendt data følges ad, hvilket er forventeligt; LAR kalder videre til CAVE, der kalder videre til database serveren. Når der er trafik ind på LAR og CAVE, må der også nødvendigvis også være trafik ud og videre til database serveren, som er den, der gemmer dataene.
Intet at bemærke.
Efter at have analyseres data fra performance testen kan følgende trækkes frem:
Derudover kan nævnes, at de 3 kald der gik galt under testen og returnerede http 500, fejlede pga. manglende svar fra en af de 3 MSB service kald: Service Unavailable.