...

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. 

...

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.

...

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.

...

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

Konklusion

MinLog2 - Performancetest rapport registration

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

Performance testen består af en række kald til 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 udføre denne gang.

...

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.

...