Page History
...
Der er intet negativt at bemærke omkring cpu forbruget eller disk io.
Jstat log
Denne log findes for hver applikations server (docker container). Både for registration og kafka-consumer. Loggen viser resultatet af kommandoen jstat. Jstat siger noget om, hvordan JVM'en har det.
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: oldx space capacity. "Ældre" hukommelses kapacitet er ikke en del af grafen men er konstant på 1.398.272 KB.
- Iterationer (sort) er baseret på det tidstempel, som findes i jstatloggen
Registration:
- Det kan være lidt svært at se graferne for 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 en enkelt gang i starten af første iteration.
- Der er en meget svag stigende tendens på den ældre hukommelse (OU_MB). Man må gå ud fra, at kommer den op på en kritisk grænse, da vil systemet køre en full garbage collection (FGC).
- 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.
Kafka-consumer:
- Her er der ikke kørt fuld garbage collecion (FGC) under testen.
- Der er ikke brug for at køre meget garbage collection på den yngre hukommelse, og den yngre hukommelse (HeapU) holdes nede.
Vurdering
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:
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:
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:
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:
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:
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