Page History

...

Der er en stigende tendens af svartiden som antallet af nodes/tråde øges. Og I Og i den sidste iteration (5) er den meget højere end I starten i starten af kørslen.

Performance kravene er

...

Kravet med maks 2 % over 15,5 sekund overholdes. Der er ingen med så høj en svartid. Derimod overholdes kravet omkring maks 5 % over 6,5 sekund ikke I ikke i flere af iterationerne. Iteration 3 har 14 % over 6,5 sekund i svartid, og iteration 5 er helt oppe på næsten 40 % over 6,5 sekund svartid. Regnes der lidt på talene, kan det ses, at sætter man en grænse på 9,2 sekund per kald er der under 5 %, der overskrider dette.

...

• Der er løbende skriv til disken mens testen kører, og I og i iteration 2-4 mest. 

Kafka-consumer:

...

Vurdering

Registration komponenten er I er i de sidste iterationer oppe at bruge 75-80 % af CPU’en. Og sammenligner man med den sidste performance test, ligger den noget højere. Men der skal også for hvert kald nu håndteres 500 registreringer mod før 1. Men der er stadig processer kraft til overs.

...

Registration: 

• Der er en svag stigning I stigning i 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 32 (docker01) henholdsvis 33 (docker02) gange i starten af første iteration.
• Den ældre hukommelse (OU_MB) ligger og svinger op og ned mens garbage collectoren holder den I den i skak, så den aldrig når sit maks (OC_MB)
• 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. 

...

• 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. Der ses dog et forskelligt mønster for de 2 servers yngre hukommelse, hvor der køres dobbelt så meget carbage collection på docker02, med dertilhørende oftere udsving I udsving i HeapU.

Vurdering

Både den yngre og ældre forbrugte hukommelse eksalerer ikke. Garbage collecterne gør sit arbejde. Noget kunne tyde på, at kafka-consumer docker02  laver noget mere end docker01.

...

• Den forbrugte hukommelse er meget stabil, dog med et lille udsving ca. ¼ henne I henne i testen

Kafka-consumer:

• Den forbrugte hukommelse er meget stabil. Det ser dog ud til, at docker01 har dobbelt så meget hukommelse til rådighed som docker02

...

• Servicen viser stabilt forbrug af hukommelse, igen med et lille hop ca. ¼ henne I henne i testen.
• Den envendte cpu er stigende som servicen bliver presset. Der sker en større forøgning mellem iteration 3 og 4. Inden for en iteration ser cpu belastningen ud til at være størst først I først i iteratioen.

Kafka-consumer:

...

• 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 opnåes i iteration 1, 2 og 3.
• 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.

...

Der ses en tendens til, at kafka-consumer docker02 har arbejdet hårdest. Kafka er sat op med 12 partitioner. Og der har været sat 12 consumers op I op i minlog per server. Dvs 24 ialt. Der har derfor været rigeligt consumers til rådighed, og dem på docker 02 er så blevet valgt. At sætte 6 consumers op per servere ville nok fordele workloaded bedre på de 2 backoffice servere.

...