Page History

...

• JMeter log data belyser
  • Faktisk antal test runder kørtiteration kørt
  • Throughput
  • (/stress01.nsp-test.netic.dk-lar/lar_listallergy_test900_stress01.nsp-test.netic.dk_master_20190513_114050.tar.gz.log)
• Access log og sla log (applikations server information) belyser
  • Antal kald per sekund
  • Svartid per kald
  • (Ex: docker01.cnsp.stage.nsp.netic.dk-lar/logs/lar/access.log)
• vmstat log (system information) belyser
  • cpu status
  • Logning sker hver 10. sekund
  • (Ex: docker01.cnsp.stage.nsp.netic.dk-lar/stats/docker01.cnsp.stage.nsp.netic.dk-cpu-20190513110936.log)
• jstat log (JVM information) belyser
  • Hukommelse (heap)  forbrug 
  • Garbage collection
  • Tidsstempel per log linie
  • (Ex: docker01.cnsp.stage.nsp.netic.dk-lar/stats/docker01.cnsp.stage.nsp.netic.dk-cave-jstat-20190513110936.log)
• docker stats log (container information) belyser
  • Hukommelse
  • io på netværk
  • Logning sker hvert sekund
  • (Ex: docker01.cnsp.stage.nsp.netic.dk-lar/stats/docker01.cnsp.stage.nsp.netic.dk-cave-container-20190513110936.log)

Hver kørsel/runde 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 rundeiteration. Filerne vmstat og docker stats har ikke tidstempler. Men da disse er startet samtidig med jstat loggen og logintervallet er kendt, kan runderne placering iterationernes placering i data beregnes.

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 iterationer er tegnet ind som lodrette mørke streger; 4 streger der sympolisere de 3 runder start iterationers 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 iterationer med test, deres tidsinterval og throughput for hver.

...

Testen har kørt med i første runde 14 iteration14 samtidige brugere, anden runde iteration 20 brugere og sidste runde 30 iteration 30 brugere. Hvilket ligger over kravet til testen. Da testen også har kørt med MSB servicen aktiveret har det lagt yderligere pres på testen. 

...

Følgende tabel viser en række beregnede data fra access loggen fordelt på applikations server (container), testrunde og test iteration og http kode. Nederst i tabellen er tallene for hver applikations server lagt sammen. Testrunde er Test iteration er beregnet ved at sammenligne tidstempel fra access log med start og sluttidspunktet for rundeniterationen. 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 runde er iteration er 900 sekunder), tidsforbrug per kald i millisekunder. 

...

Af tabellen fremgår det, at jo flere brugere (brugere øges per rundeiteration) jo flere kald kommer der igennem per sekund. Tallene svarer overens med de tal JMeter kom frem til som throughput.

Det ses, at jo flere brugere 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 14 brugere (runde iteration 1) er svartiden 155 ms. Vi er inden for performance kravet.

...

• 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 iterationer 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 runderiterationer. 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.

...

• YGC: young generation garbage collection events, antal af "ung" 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 iterationer er baseret på det tidstempel, som findes i jstatloggen

For LAR kan man se, at der er kørt et par enkle fuld garbage collections. Ved start af runde iteration 1 og midt i runde iteration 3. 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. 

...

• memoryUsage: den totale mængde hukommelse containeren bruger
• memoryLimit: den totale mængde hukommelse contaneren kan bruge
• De 3 runder er iterationer er en cirka placering, da docker stats loggen ikke indeholder tidstempel

...

• cpuPct: hvor mange procent af hostens cpu containeren bruger
• memoryPct: hvor mange procent af hostens hukommelse containeren bruger
• de 3 runder er iterationer er en cirka placering, da docker stats loggen ikke indeholder tidstempel

...

• 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 iterationer 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 forventeligt

Vurdering

Placeringen af rundernes markering iterationernes 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.

...