Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

...

Throughput falder mellem iteration 11 og 12. Og der er en forøgning af fejl i den sidste iteration.

Access log

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:


Vurdering

TODO

Vmstat log

Denne log findes for hver applikations server (docker container). Den viser resultatet af kommandoen vmstat

...

MinLog2 - Performancetest rapport minlog1 lookup

JMeter log

JMeter hoved filen beskriver overordnet testens resultat. Her kan  kan ses, at der er kørt 4 iterationer med test, deres tidsinterval , throughput og fejlprocent for hver.

Performance testen består af en række kald til opslag efter logninger på forskellige cpr numre. Denne test er samme type som borger lookup. Den anvender dog istedet minlog1 formatet.

Testen udført er komponent "minlog", testplan "listlogstatements" og distribution "borger".

MinLog 2 service er version 2.0.25perf og NSP standard performance test framework version 2.0.20

De rå test resultater er vedhæftet denne side (TODO)

JMeter log

JMeter hoved filen beskriver overordnet testens resultat. Her kan  kan ses, at der er kørt 4 iterationer med test, deres tidsinterval , throughput og fejlprocent for hver.

Iteration

Tråde

Nodes

Starttid

Sluttid

Throughput

Fejlprocent
15

Iteration

Tråde

Nodes

Starttid

Sluttid

Throughput

Fejlprocent
1522020-03-09_10-16-282020-03-09_10-31-3433,93 kald per sekund0 %
2822020-03-09_10-32-342020-03-09_10-47-3949,51 kald per sekund0 %

3

1122020-03-09_10-48-312020-03-09_11-03-3759,11 kald per sekund0 %
41132020-03-09_11-04-422020-03-09_11-19-4769,49  kald per sekund0 %

Det fremgår også af filen, at den endelige måling af throughput er 69,49 kald per sekund.

Samt at fejlprocentet på den fulde kørsel er 0 %. 

Access log

Image Removed

Image Removed

Image Removed

Vmstat log

Image RemovedImage Removed

Image RemovedImage Removed

Jstat log

Image RemovedImage Removed

Docker stats log

Image RemovedImage Removed

Image RemovedImage Removed

Image RemovedImage Removed

...

-16-282020-03-09_10-31-3433,93 kald per sekund0 %
2822020-03-09_10-32-342020-03-09_10-47-3949,51 kald per sekund0 %

3

1122020-03-09_10-48-312020-03-09_11-03-3759,11 kald per sekund0 %
41132020-03-09_11-04-422020-03-09_11-19-4769,49  kald per sekund0 %

Det fremgår også af filen, at den endelige måling af throughput er 69,49 kald per sekund.

Samt at fejlprocentet på den fulde kørsel er 0 %. 

Access log

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:

Image Added


Image Added

Den næste graf viser antal kald per sekund:

Image Added

Vurdering

TODO

Vmstat log

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:

Image AddedImage Added

Data serier i grafen er:

  • cpuNonKernel (rød): tid brugt på non-kernel opgaver
  • cpuKernel (blå): tid brugt på kernel opgaver
  • cpuIdle (grøn): tid brugt på ingenting
  • cpuWaitIO (gul): tid brugt på at vente på i/o
  • iterationerne (sort) er en cirka placering, da wmstat loggen ikke indeholder tidstempel

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

Image AddedImage Added

Data serier i grafen er:

  • ioBlockRead (rød): læsning på disk (blokke)
  • ioBlockWrite (blå): skriving  på disk (blokke)
  • iterationerne (sort) er en cirka placering, da wmstat loggen ikke indeholder tidstempel

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 store udsving i skrivninger falder sammen med at cpuKernal går op og cpuIdle går ned. 

Vurdering

TODO

Jstat log

Denne log findes for hver applikations server (docker container). 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 grafer:

Image AddedImage Added

Data serier i grafen er:

  • YGC (rød): young generation garbage collection events, antal af "ung" garbage collection siden start
  • FGC (blå): full garbage collection events, antal af fuldstændig garbage collection siden start
  • HeapU (gul): består af S0U+S1U+EU fra jstat loggen. Young generation memory utilization. "Ung" hukommelses forbrug
  • HeapC (grøn): består af S0C+S1C+EC fra jstat loggen. Young generation memory capacity. "Ung" hukommelses kapacitet
  • OU_MB (pink): old space utilization. "Ældre" hukommelses forbrug
  • OC: old space capacity. "Ældre" hukommelses kapacitet er ikke en del af grafen men er konstant på 1.398.272 KB. 
  • Iterationer (sort) er baseret på det tidstempel, som findes i jstatloggen

Det kan være lidt svært at se graferne for full garbage collection (FGC). Kigger man nærmere på datagrundlaget bag graferne, ses det, at der ikke er full garbage collection for servicen under testen. 

Der er en meget svag stigende tendens på den ældre hukommelse (OU_MB). Man må gå ud fra, at kommer den op på en kritisk grænse, da vil systemet køre en full garbage collection (FGC).

Der køres ofte garbage collection på den yngre hukommelse, hvilket holder HeapU - yngre hukommelses forbrug - nede så den kun svinger inden for et konstant interval.

Vurdering

TODO

Docker stats log

Denne log findes for hver applikations server (docker container). Loggen viser resultatet af kommandoen docker stats. Docker stats siger noget om, hvordan containeren forbruger sine ressourcer.

Udtræk omkring hukommelse, cpu og netværkstrafik vises i følgende grafer.

Hukommelse:

Image AddedImage Added

Data serier i grafen er:

  • memoryUsage (rød): den totale mængde hukommelse containeren bruger
  • memoryLimit (blå): den totale mængde hukommelse contaneren kan bruge

Den forbrugte hukommelse er meget stabil.

Cpu og hukommelse procent:

Image AddedImage Added

Data serier i grafen er:

  • cpuPct (rød): hvor mange procent af hostens cpu containeren bruger
  • memoryPct (blå): hvor mange procent af hostens hukommelse containeren bruger

Servicen viser et stabilt forbrug af hukommelse. Den envendte cpu er svagt stigende som servicen bliver presset.

Netværk:

Image AddedImage Added

Data serier i grafen er:

  • netIn (rød): den mængde data som er modtaget af containeren over netværket
  • netOut (blå): den mængde data som er sendt ud af containeren over netværket

De 2 grafer for ind- og udsendt data følges ad, hvilket er forventeligt; indkomne kald skaber trafik til database og igen retur til kalder. netIn stiger mest.

Konklusion

TODO