Page History

...

Den yngre forbrugte hukommelse eskalerer ikke. Garbage collecteren gør sit arbejde.

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 ModifiedImage Modified

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.

Kafka-consumer:

• Den forbrugte hukommelse er meget stabil.

Cpu og hukommelse procent:

Image ModifiedImage Modified

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 et stabilt forbrug af hukommelse. Den envendte cpu er stigende som servicen bliver presset.

Kafka-consumer:

• Både forbruget af hukommelse og cpu er stabilt igennem testen.

Netværk:

Image ModifiedImage Modified

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 følges ad, hvilket er forventeligt; indkomne kald skaber trafik.

Kafka-consumer:

• De 2 grafer for ind- og udsendt data stiger svagt og følges ad.

Kafka consumer lag

Denne log findes for hver applikations server (docker container). Både for registration og kafka-consumer. 

For registration siger den noget om, hvor hurtigt mirrorMaker  er til at tage fra på den "lokale" kafka og lægge ting over i  den centrale kafka på backoffice. For kafka-consumer siger den noget om, hvor hurtigt der tages fra på den centrale kafka og ned i databasen.  Lag er forskellen mellem det data som bliver produceret (producer) til kafka og forbrugt (consumer) af kafka.

Udtræk omkring registerings komponentens kafka og lag i løbet af testen:

Image ModifiedImage Modified

Data serier i grafen er:

• lag (rød): den lag som findes på et givet tidspunkt

Registeringskomponentens kafka har kun en partition, om man kan se at lag stiger som testen skrider frem.

Udtræk omkring den centrale kafka og lag i løbet af testen:

Image Modified

Data serier i grafen er:

• 0 (rød): den lag som findes på et givet tidspunkt for partition 0
• 1 (blå): den lag som findes på et givet tidspunkt for partition 1
• 2 (grøn): den lag som findes på et givet tidspunkt for partition 2
• 3 (gul): den lag som findes på et givet tidspunkt for partition 3
• 4 (pink): den lag som findes på et givet tidspunkt for partition 4
• 5 (tyrkis): den lag som findes på et givet tidspunkt for partition 5

Den centrale kafka har 6 partitioner, og man kan se, at lag stiger som testen skrider frem. 

Vurdering

Både registrering komponentens kafka og den centrale kafka har det bedst før iteration 7. Herefter kan læsningen ikke rigtig følge med input. Registreringskomponentens kafka er den, som har de største peaks inden iteration 7, og kunne  gøres mere effektiv, ved at tilføje flere partitioner til den ene, den har nu.

Konklusion

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

• Throughput på testen er 52,96 kald per sekund
  
  
• Svartid for servicen: 
  Kravet er 95% skal være under 6,5 sekund og 98 % under 15,5 sekund. Resultatet viste 99,5 % lå under både 6,5 og 15,5 sekund.
  
  
• Cpu status: cpu forbruget stiger lidt over test perioden, som  registration servicen presses mere. Dog kun kortvarigt.
  
  

• io på netværk: stiger over tid, hvilket er forventet
  
  
• Hukommelses forbrug: servicen håndterer brug af hukommelse fint
  
  
• 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: når iteration 7 og 8 viser alle 3 kafka instanser tegn på at lag stiger end del

Oprindeligt planlagt skulle der være kørt 2 applikationer med registration komponenten. Istedet er testen kørt med 4 applikationer, hvorfor man kan forvente at servicen i testen, får et højere throughput isoleret set på en given iteration, og belastningen på den enkelte applikation lavere end, hvis det samme throughput skulle have været udført at 2.

Når det er sagt, kører der i produktion 18 registrerings komponenter fordelt på dNSP og cNSP, så her vil maskinkraften være højere end i det anvendte test setup.

Kafka-consumer komponenten har arbejdet med data, produceret fra 4 applikationer og er derfor blevet mere belastet end oprindeligt planlagt.

Ser man på graferne over de forskellige iterationer, er iteration 6 er den sidste, som er mest sund: Herefter stiger svartider og resource forbruget de forskellige steder. 

Iteration 6 har 37,73 kald per sekund. Dette bliver til ca. 23 mio kald på en uge. Det er hvad den centrale kafka-consumer håndterer uden at vise tegn på problemer. Og man må forvente at 18 registreringskomponenter i produktion vil kunne følge med her, når de 4 i testen kunne.