Page History

...

Performance testen består af en række kald til registrering af minlog2 data med forskellige cpr numre. I den kørte test, er der 500 registreringer per kald. Sidst, der blev kørt performance test for registration var der kun een registrering per kald. Så for hvert kald der laves, er der mere arbejde at laveudføre denne gang.

Testen, som er udført er, komponent "minlog2", testplan "registration" og distribution "test300_500".

MinLog 2 service er version 2.0.45 og NSP standard performance test framework version 2.0.27.

Der analyseres access og stats log fra registration komponenten, samt stats log fra kafka-consumer komponenten. Derudover ses der på kafka consumer lag for begge.

...

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_MB (tyrkis): old space capacity. "Ældre" hukommelses kapacitet er konstant på 1.398.272 KB. 
• Iterationer (sort) er baseret på det tidstempel, som findes i jstatloggen

Registration: 

• Der er en svag stigning I full garbage collection (FGC). Kigger man nærmere på datagrundlaget bag graferne, ses det, at der kørt full garbage collection for servicen under testen 32 (docker01) henholdsvis 33 (docker02) gange i starten af første iteration.
• Den ældre hukommelse (OU_MB) ligger og svinger op og ned mens garbage collectoren holder den I skak, så den aldrig når sit maks (OC_MB)
• 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. 

...

Både den yngre og ældre forbrugte hukommelse eksalerer ikke. Garbage collecterne gør sit arbejde. Noget kunne tyde på, at kafka-consumer docker02  laver noget mere end docker01.

Docker stats log

Denne log findes for hver applikations server (docker container). Både for registration og kafka-consumer. 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 grafer.

Hukommelse:

Image AddedImage Added

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

Registration:

• Den forbrugte hukommelse er meget stabil, dog med et lille udsving ca. ¼ henne I testen

Kafka-consumer:

• Den forbrugte hukommelse er meget stabil. Det ser dog ud til, at docker01 har dobbelt så meget hukommelse til rådighed som docker02

Cpu og hukommelse procent:

Image AddedImage Added

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

Registration:

• Servicen viser stabilt forbrug af hukommelse, igen med et lille hop ca. ¼ henne I testen.
• Den envendte cpu er stigende som servicen bliver presset. Der sker en større forøgning mellem iteration 3 og 4. Inden for en iteration ser cpu belastningen ud til at være størst først I iteratioen.

Kafka-consumer:

• Både forbruget af hukommelse og cpu er stabilt igennem testen. Dog har docker02 klart mest at lave.

Netværk:

Image AddedImage Added

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

Registration:

• De 2 grafer for ind- og udsendt data stiger. Indkommen trafik stiger mest

Kafka-consumer:

• For docker01 stiger de 2 grafer for ind- og udsendt data svagt og følges ad. På docker02 stiger begge grafer noget mere, og netIn stiger enddag rigtig meget.

Vurdering

Det ser ud til at, kafka consumer har haft mest at lave på docker02, so presset på de 2 servere har været skævt fordelt.

Kafka consumer lag

Vurdering

...