Page History
...
- Tjek "?" og se om rigtigt eller manglende
- Hvad hedder young og old space på dansk? afsnittet omkring jstat skal justeres på denne baggrund
- prøv at se grafer for lar container kørt med interval 1200 (ikke 900) . De har ligesom 4 runder
- container grafer skal skiftes ud. interval kan ikke genberegnes. skal være enten 900 (1 linie pr sek) eller 1896 (hele loggen fordelt ud på 3 intervaller). Men ingen af dem kommer til at matche. What to do?
- overvej om tabel i afsnit access log kun skal indeholde summer af alle app serverne og ikke fordelingen
- [hvad kan man udlede af heapC op grafen for jstat???]
- vurderinger for hver log fil
- konklusion for hvert punkt nævnt først i afsnit "performance tal"
...
Hver kørsel/runde (ø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 runde. Filerne vmstat og docker stats har ikke tidstempler. Men da disse er startet samtidig med jstat loggen og logintervallet er kendt, kan runderne placering i data beregnes.
JMeter log data
JMeter hoved filen beskriver overordnet testens resultet.
Her kan kan ses, at der er kørt 3 runder med test, deres tidsinterval og throughput for hver.
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 runder er tegnet ind som lodrette mørke streger; 4 streger der sympolisere de 3 runder start og slut.
JMeter log data
JMeter hoved filen beskriver overordnet testens resultet.
Her kan kan ses, at der er kørt 3 runder med test, deres tidsinterval og throughput for hver.
| Runde | Tråde | Nodes | Runde | 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 |
...
Derfor konkluderes at ud fra JMeter loggens data ser testens resultat fornuftig ud i forhold til performance kravet.
Access log data
For Denne log findes for hver applikations server (docker container) er der en access log for både LAR og CAVE servicen.
...
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. Dette burde give bedre performance.
Vmstat log
For Denne log findes for hver applikations server (docker container) findes der en log, som viser resulatet . Den viser resultatet af kommandoen vmstat. Kommandoen er kørt hver 10. sekund.
Udtræk omkring cpu fra denne log vises i de følgende 4 grafer.
(fra venstre mod højre og ned og mod højre: app server 1, 2, 3 og 4, klik på den enkelt graf for større billede)
De 3 runder er tegnet ind med mørke lodrette streger. Placeringen er cirka, da wmstat loggen ikke indeholder tidstempel. Istedet er beregnet ud fra start og slut på testen fordelt på perioden.
De 4 data serier i grafen er:
De 4 data serier i grafen er:
- cpuNonKernel: tid brugt på non-kernel opgaver
- cpyKernel:
- cpuNonKernel: tid brugt på non-kernel opgaver
- cpyKernel: tid brugt på kernel opgaver
- cpuIdle: tid brugt på ingenting
- cpuWaitIO: tid brugt på at vente på i/o
- De 3 runder er en cirka placering, da wmstat loggen ikke indeholder tidstempel
De 4 dataserier i graferne er meget stabile. Man fornemmer aktivitet omkring start og slut af de 3 runder. Størst udsving er der ved opstart af testen, hvor den cpu der bliver brugt af applikationen (cpuNonKernel) striger meget og idle cpu tilsvarende falder. Men det er kun kortvarigt.
...
Graferne ser fornuftige ud. Der er intet at bemærke omkring cpu forbrug.
Jstat log
For Denne log findes for hver applikations server (docker container) findes der 2 logge, som viser resulatet af kommandoen jstat. En - 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:
(fra venstre mod højre og ned og mod højre: app server 1, 2, 3 og 4, klik på den enkelt graf for større billede)
De 3 runder er tegnet ind med mørke lodrette streger baseret på det tidstempel som findes i jstatloggen. De 5 data serier i De 5 data serier i grafen er:
- YGC: young generation garbage collection events, antal af ung generation garbage collection siden start
- FGC: full garbage collection events, antal af fuldstændig garbage collection siden start
- HeapU: består af S0U+S1U+EU fra jstat loggen. Young generation memory utilization. Ung hukommelses forbrug
- HeapC: består af S0C+S1C+EC fra jstat loggen. Young generation memory capacity. Ung hukommelses kapacitet
- OU_MB: 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 for både LAR og CAVE.
- De 3 runder er baseret på det tidstempel, som findes i jstatloggen
For LAR kan For LAR kan man se, at der er kørt et par enkle fuld garbage collections. Ved start af runde 1 og midt i runde 3. For CAVE kan man se, at der ikke er kørt fuld garbage collection. Der køres også oftere carbage garbage collection på den unge hukommelse på LAR servicen end der gør på CAVE.
Den brugte unge hukommelse svinger noget for både LAR og CAVE, men dog i et konstant interval.[hvad kan man udlede af heapC???]
Vurdering
Den unge forbrugte hukommelse eskalerer ikke for hverken LAR eller CAVE.
...
Dog øges den ældre hukommelse over tid for LAR servicen.
Docker stats log
For Denne log findes for hver applikations server (docker container) findes der 2 logge, som viser resulatet - en for LAR og en for CAVE. Loggen viser resultatet af kommandoen docker stats. En for LAR og en for CAVE. Kommandoen er kørt hvert sekund. Docker 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:
(fra venstre mod højre og ned og mod højre: app server 1, 2, 3 og 4, klik på den enkelt graf for større billede)
De 3 runder er tegnet ind med mørke lodrette streger. Placeringen er cirka, da docker stats loggen ikke indeholder tidstempel. Istedet er beregnet ud fra start og slut på testen fordelt på perioden.
De 2 data serier i grafen er:
- memoryUsage: den totale mængde hukommelse containeren bruger
- memoryLimit: den totale mængde hukommelse contaneren kan bruge
Den forbrugte hukommelse for CAVE servicen er meget stabil. For LAR servicen er den svagt stigende.
LAR service - Cpu og hukommelse procent
CAVE service - Cpu og hukommelse procent
(fra venstre mod højre og ned og mod højre: app server 1, 2, 3 og 4, klik på den enkelt graf for større billede)
De 3 runder er tegnet ind med mørke lodrette streger. Placeringen er cirka, da docker stats loggen ikke indeholder tidstempel. Istedet er beregnet ud fra start og slut på testen fordelt på perioden.
De 2 data serier i grafen er:
- cpuPct: hvor mange procent af hostens cpu memoryUsage: den totale mængde hukommelse containeren bruger
- memoryPct: hvor mange procent af hostens hukommelse containeren bruger
Begge procenter er stabil for CAVE servicen. LAR servicen viser et stigende forbrug af hukommelse.
- memoryLimit: den totale mængde hukommelse contaneren kan bruge
- De 3 runder er en cirka placering, da docker stats loggen ikke indeholder tidstempel
Den forbrugte hukommelse for CAVE servicen er meget stabil. For LAR servicen er den svagt stigende.
LAR service - Cpu og hukommelse procent:LAR service - netværk
CAVE service - NetværkCpu og hukommelse procent:
(fra venstre mod højre og ned og mod højre: app server 1, 2, 3 og 4, klik på den enkelt graf for større billede)
De 3 runder er tegnet ind med mørke lodrette streger. Placeringen er cirka, da wmstat loggen ikke indeholder tidstempel. Istedet er beregnet ud fra start og slut på testen fordelt på perioden.
De 2 data serier i grafen er:
- cpuPct: hvor mange procent af hostens cpu containeren bruger
- memoryPct: hvor mange procent af hostens hukommelse containeren bruger
- de 3 runder er en cirka placering, da docker stats loggen ikke indeholder tidstempel
Begge procenter er stabil for CAVE servicen. LAR servicen viser et stigende forbrug af hukommelse.
LAR service - netværk
CAVE service - Netværk:
De 2 data serier i grafen er:
- netIn - den mængde data som er modtaget af containeren over netværket
- netOut - den mænde data som er sendt ud af containeren over netværket
- de 3 runder er en cirka placering, da docker stats loggen ikke indeholder tidstempel
De 2 grafer for ind- og udsendt data følges pænt, hvilket er forventligt. forventeligt
Vurdering
Placeringen af rundernes markering kunne umiddelbart godt se forkert ud når man generelt ser på graferne. Der er ændret adfærd ca. 150 enheder før den angivne markering første gang, og den bliver længere og længere til venstre.
Derforuden...
Konklusion
TBD
Fejlprocess vurdering,
...