...

Cpu forbruget på docker02 bør tjekkes, hvorfor det ikke falder igen.

Konklusion

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

• Througput for servicen:
  • max throughput på testen blev aldrig nået. Så det bedste tal er 112.02 kald per sekund
  • servicen kører bedst ved iteration 9, med et throughput på 103, 9 kald per sekund
• Svartid for servicen:
  • For 95 % percentil: under 0,8 sekund
  • For 98 % percentil: under under 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. Den ene server tager et spring i sidste iteration, men ellers ser det fornuftigt ud.
• io på netværk:
  • stiger over tid, hvilket er forventet
• Hukommelses forbrug:
  • servicen håndterer brug af hukommelse fint.
  • 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 og dermed stiger hukommelses forbruget ikke over tid. Dette er et tegn på, at vi ikke har memory leaks.

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

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

Analysen har et enkelt punkt, der eventuelt skal undersøges nærmere. I iteration 10, viser den ene server lidt afvigende opførsel på cpu forbrug. Den stiger mere end tidligere og falder ikke til samme lave niveau, som tidligere efter endt iteration.

MinLog2 - Performancetest rapport medhjælper lookup

...

• Througput for servicen:
  • max throughput på testen er 6,25 kald per sekund (dvs 3125 registreringer per sekund, da et kald indeholder 500 registreringer)
  • servicen kører bedst ved et throughput på 4,19 kald per sekund (2095 registreringer per sekund).
• Svartid for servicen:
  • kravet er 95% skal være under 6,5 sekund og 98 % under 15,5 sekund.
  • Dette opnåes i iteration 1, 2 og 4.
• Cpu status:
  • cpu forbruget stiger lidt over test perioden, som registration servicen presses mere.
• io på netværk:
  • stiger over tid, hvilket er forventet. input på docker02 for kafka consumer stiger dog rigtig meget
• Hukommelses forbrug:
  • servicen håndterer brug af hukommelse fint.
  • at der er dobbelt så meget hukommelse på kafka-consumer docker02 end på docker01 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 og dermed stiger hukommelses forbruget ikke over tid. Dette er et tegn på, at vi ikke har memory leaks.
• Kafka Consumer Lag:
  • for hver iteration viser de lokale kafka instancer tegn på, at lag stiger. Den centrale kafka opbygger en del lag.

...