Page History

...

JMeter hoved filen beskriver overordnet testens resultat. Her kan  kan ses, at der er kørt 8 iterationer med test, belastningen i form af tråde og nodes, deres tidsinterval , throughput og fejlprocent for hver.:

...

Følgende tabel viser en række beregnede data fra access loggen fordelt på applikations server (container) og test iteration. Nederst i tabellen er tallene for hver applikations server lagt sammen. Test . Denne sum er kun ca. halvdelen af, hvad der totalt er håndteret, da log filerne kun findes  for 2 applikationer servere. Test iteration er beregnet ved at sammenligne tidstempel fra access log med start og sluttidspunktet for iterationen. 

...

Af tabel og grafer fremgår det, at jo flere nodes og tråde (disse øges per iteration) jo flere kald kommer der igennem per sekundtidsenhed. 

Det ses, at svartiden ikke ændres i starten, fordi antallet af nodes/tråde øges. Først i iteration 7 bliver svartiden forøget.

...

• cpuNonKernel (rød): tid brugt på non-kernel opgaver
• cpuKernel (blå): tid brugt på kernel opgaver
• cpuIdle (grøn): tid brugt på ingenting
• cpuWaitIO (gul): tid brugt på at vente på i/o
• iterationerne (sort) er en cirka placering, da wmstat loggen ikke indeholder tidstempel

Registration:

• Man kan se at cpuIdle og cpuNonKernel påvirkes lidt som servicen presses mere. cpuIdle ligger lavere over tid, mens cpuNonKernel grafen ligger en smule højere over tid. Den generelle flyt ændring af kurverne er dog ikke faretruende. I iteration 7 og 8 er der lidt mere udsving for docker02.

...

Udtræk omkring io læs og skriv fra vmstat vises i de følgende grafer.:

Data serier i grafen er:

• ioBlockRead (rød): læsning på disk (blokke)
• ioBlockWrite (blå): skriving  på disk (blokke)
• iterationerne (sort) er en cirka placering, da wmstat loggen ikke indeholder tidstempel

...

• Det kan være lidt svært at se i 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. 

...

• Servicen viser et stabilt forbrug af hukommelse. Den envendte cpu er stigende som servicen bliver presset. Der sker et lille hop i iteration 7 og 8

Kafka-consumer:

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

...

• De 2 grafer for ind- og udsendt data følges ad, hvilket er forventeligt; indkomne kald skaber trafik.stiger. Indkommen trafik stiger mest

Kafka-consumer:

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

Vurdering

Intet at bemærke.

Kafka consumer lag

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

For registration siger den fortæller loggen 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 fortæller den noget om, hvor hurtigt, der tages fra på den centrale kafka og ned i databasen.  Lag er forskellen mellem det de data, som bliver produceret (producer) til kafka og forbrugt (consumer) af fra kafka køen.

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

...

Registeringskomponentens kafka har kun en partition, om man kan se at lag stiger som testen skrider frem. Især i de senerer iterationer lag ikke at komme ned inden ny data får den til at stige igen.

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

...

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.

...

• 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.