...

Dette dokument indeholder analyse af log data fra den anden performance test, som er kørt for Minlog2. Den indeholder en analyse af de log data, som er samlet op under test kørslenTestene er kørt december 2020. Analysen dækker

• MinLog2 - Performancetest rapport borger lookup
• MinLog2 - Performancetest rapport medhjælper lookup
• MinLog 2 - Performancetest rapport registration

...

Der er lidt løbende skriv til disken mens testen kører

Vurdering

Der er generlt intet negativt at bemærke omkring cpu forbruget eller io. Dog er der lidt afvigelse i mønstret for cpu forbruget i iteration 10.

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. 

...

Det ses af graferne, at jo flere nodes/tråde jo højere bliver svar tiden overordnet set. Og især til sidstved iteration 5, hvor den ene server er gået i stå, stiger svartiderne for den anden, der stadig kører.

...

Servicen kørende på Docker01, som fik problemer sidst i testen problemer  ved iteration 5 har dog ingen kald i de siste 3 iterationersidste 2,5 iteration.

Vurdering

Performance kravene

...

Vi er inden for performance kravene i testen fulde køretid, selv i de test iterationer, hvor den ene af de testede service stoppede og den anden måtte arbejde selv..

Vmstat log

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

...

Man kan se at cpuIdle og cpuNonKernel påvirkes som servicen presses mere. cpuIdle ligger lavere over tid, mens cpuNonKernel grafen ligger højere over tid. Ved testens. 5 iteration stiger cpuNonKernal fra at lægge

Hen ved testens 5. iteration sker der dog en stor ændring i dette mønster. Her stiger cpuNonKernal fra at ligge under 50 % til at komme over og til sidst ramme 90 %. For docker01 vedkommende stiger den meget brat og rammer næsten 100 %.

...

Der er løbende skriv til disken mens testen kører.

Vurdering

Cpu forbruget i 5. og efterfølgende iterationer kan give grund til bekymring.

...

Der er en svag stigende tendens på den ældre hukommelse (OU_MB). Og fra iteration 5, stiger den en del, især for docker01, hvor den faktisk rammer loftet på 1.398.272 KB, og ikke kører længere.

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. 

...

• 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 testeniteration 5, hvor den for især docker1 stiger brat.Den forbrugte hukommelse er meget stabil indtil iteration 5, hvor den stigerstiger og derefter er stabil igen.

Cpu og hukommelse procent:

...

Den envendte cpu er svagt stigende som servicen bliver presset. Og fra 5. iteration laver både docker01 og docker02 nogle høje spring i cpu forbruget.

...

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. Dog flader docker02 ud i iteration 5 og har ikke mere trafik.

Vurdering

Disse log data viser igen den øgede cpu og hukommelsesforbrug fra iteration 5 i testen. 

Konklusion

. netOut stiger mest. Dog flader docker02 ud i iteration 5 og har ikke mere trafik, efter servicen er stoppet.

Vurdering

Disse log data viser igen den øgede cpu og hukommelsesforbrug fra iteration 5 i testen. 

Konklusion

Efter at have analyseres data fra performance testen kan følgende trækkes frem:

• Througput for servicen:
  • throughput på testen er 50,03 kald per sekund.
  • servicen kører bedst ved iteration 4, med et throughput på 37,42 kald per sekund
• Svartid for servicen:
  • for 95 % percentil: under 1,8 sekund
  • for 98 % percentil: under under 2,1 sekund
  • kravene på under 2,5 henholdsvis 5,5 sekunder er overholdt
• Cpu status:
  • cpu forbruget stiger over test perioden, som servicen presses mere. I iteration 5 kommer den ene server i problemer med cpu forbruget
• io på netværk:
  • stiger over tid, hvilket er forventet
• Hukommelses forbrug:
  • servicen ser ud til at få problemer med hukommelsen når den presses
  • at der er dobbelt så meget hukommelse på på den ene server, burde ikke have nogen konsekvenser for testen, da Wildfly’en er sat op til at køre med 2 GB begge steder
• Garbage collection:
  • servicen kører jævnligt garbage collection
  • noget kunne tyde på, at når servicen bliver presset, kan garbage collection ikke helt få ryddet op

Ser man på graferne over de forskellige iterationer, er iteration 4 den, som ser sundest ud. Den overholder kravene til svartider, belastning på cpu og memory ser fornuftigt ud.

Iteration 4 har 37,42 kald per sekund . Dette bliver til ca. 23 mio kald på en uge. Det er hvad test setup’et kunne håndtere uden at vise tegn på problemer.

Performance testen er designet til at presse en service mere og mere. Medhjælper lookup viser en svaghed, når den presses og når til iteration 5, som er 17 tråde og 2 nodes. Det bør undersøges, hvordan denne belastning ligger i forhold til, hvad der forventes i drift, for at vurdere, om det vil blive et faktisk problem.

Den kraftige forøgelse af cpu og hukommelses forbrug bør undersøges. Kombinationen kunne måske tyde på loop. Dette bør undersøges nærmere i andre log filer eller en fokuseret test rettet mod dette.

Da testen bliver afbrudt i mangel på hukommelse, viser den ikke, om vi faktisk har nået det maksimale throughput den ellers ville have kunnet yde. Allokering af mere hukommelse til servicen kunne afhjælpe dette.

MinLog2 - Performancetest rapport registration

...

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

...