Page History
...
Throughput falder mellem iteration 11 og 12. Man kunne overveje, om Og der er en relation mellem dette og den høje fejlprocent i iteration 12forøgning af fejl i den sidste iteration.
Access log
Vmstat log
Jstat log
Docker stats 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
Udtræk omkring cpu fra denne log vises i de følgende grafer:
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.
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.
Hen ved testens 10. iteration sker der dog en stor ændring i dette mønster. Her stiger cpuNonKernal meget fra at ligge under 50 % til at komme over. For docker1 vedkommende bliver den ved at stige til den rammer næsten 100 % og for docker2 lander den på 85%
Udtræk omkring io læs og skriv fra vmstat vises i de følgende grafer:
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 få store udsving i skrivninger falder sammen med at cpuKernal går op og cpuIdle går ned. Dog ses en markant stigning i antal af skriv til disk i samme periode som cpuNonKernel stiger.
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:
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
For docker2 køres der ikke full garbage collection (FGC) under testen. docker1 får dog brug for dette i testen sidste iteration, hvor der køres ialt 181 gange full garbage collection.
Der er en svag stigende tendens på den ældre hukommelse (OU_MB). Og i sidste iteration stiger den en del, især for docker1, hvor den faktisk rammer loftet på 1.398.272 KB.
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:
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 indtil sidst i testen, hvor den for især docker1 stiger brat.
Cpu og hukommelse procent:
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 i starten af testen, men igen ses en stigning sidst i testen især på docker1.
Den envendte cpu er svagt stigende som servicen bliver presset. Og fra 10. iteration laver både docker1 og docker2 nogle høje spring i cpu forbruget.
Netværk:
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. netOut stiger mest.
Konklusion
TODO
MinLog2 - Performancetest rapport minlog1 lookup
...
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 |
|---|---|---|---|---|---|---|
| 1 | 5 | 2 | 2020-03-09_10-16-28 | 2020-03-09_10-31-34 | 33,93 kald per sekund | 0 % |
| 2 | 8 | 2 | 2020-03-09_10-32-34 | 2020-03-09_10-47-39 | 49,51 kald per sekund | 0 % |
3 | 11 | 2 | 2020-03-09_10-48-31 | 2020-03-09_11-03-37 | 59,11 kald per sekund | 0 % |
| 4 | 11 | 3 | 2020-03-09_11-04-42 | 2020-03-09_11-19-47 | 69,49 kald per sekund | 0 % |
Det fremgår også af filen, at den endelige måling af throughput er 69,49 kald per sekund.
...