...

• NAS 2 notification broker service
• NAS 2 pull point service

Først beskrives de forskellige typer test data output, og hvordan de anvendes i analysen. Derefter skitseres performance kravene for begge test. Og herefter analyses data.

Analysen af performance test dataene har ikke givet anledning til bekymring eller identificering af flaskehalse.

Performance analyse

For begge test gælder følgende:

...

• NAS 2 Notification Broker service version 2.0.6
• NSP kafka
• Gallera Galera MariaDB cluster
• NSP standard performance test framework version 2.0.10

...

Kravet til testen er, at der skal køres med 10 adviseringer (kald) i sekundet. NSP's test framework fungerer med en bestemt belastning i testen som gradvis øges. I første iteration har testen kørt med 400 kald per sekund, hvilket ligger højt over kravet til testen.  

...

Følgende tabel viser en række beregnede data fra access loggen fordelt på applikations server (container), test iteration og http kode. Nederst i tabellen er tallene for hver applikations server lagt sammen. Test iteration er beregnet ved at sammenligne tidstempel fra access log med start og sluttidspunktet for iterationen. Http koden findes i access loggen (kald returnerede med fejl (500) eller ingen fejl(200)).

...

• netIn (rød): den mængde data som er modtaget af containeren over netværket
• netOut (blå): den mænde mængde data som er sendt ud af containeren over netværket

TBD

Vurdering

...

Kafka statistik

De 2 grafer for ind- og udsendt data følges ad, hvilket er forventeligt; indkomne kald skaber trafik til kafka og igen retur til  kalder.

Vurdering

Intet at bemærke.

Kafka statistik

De følgende grafer følgende grafer er lavet på baggrund af vmstat data på kafka serveren.

...

• Svartid per kald til servicen: 9 ms for 2 nodes og 5 tråde, og med et throughput på 399 kald per sekund
  Kravet er, at et kald skal tage mindre end 250 ms med 10 adviseringer hver sekund.
  Dette opfyldes så rigeligt, endda under øget belastning med flere nodes og tråde.
  Der er kald, som tager mere end 500 ms, men det er så få, at procentvis er det 0 %.
  
  
• Cpu status: cpu forbruget stiger lidt over test perioden, som servicen presses mere.Dog kun kortvarigt.
  
  
• io på netværk: todo
  
  
• 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: Hverken disk skriv/læs eller cpu forbrug giver anledning til bekymring for om kafka serverne påvirker servicens performance negativt

Analysen af performance test data for notification broker har ikke givet anledning til bekymring eller identificering af flaskehalse.

Pull Point

Scope

Performance testen består af en række kald til læsning af pull points.

...

Følgende tabel viser en række beregnede data fra access loggen fordelt på applikations server (container), test iteration og http kode. Nederst i tabellen er tallene for hver applikations server lagt sammen. Test iteration er beregnet ved at sammenligne tidstempel fra access log med start og sluttidspunktet for iterationen. Http koden findes i access loggen (kald returnerede med fejl (500) eller ingen fejl(200)).

...

Udtræk af svartid og antal kald fordelt over testens løbetid vises i følgende grafer:

GRAF2Image AddedImage Added

Data serier i grafen er:

• DurationAverage (rød): den gennemsnitlige svartid (ms) for hvert minut
• Iterationer (sort) er baseret på det tidstempel, som findes i loggen

GRAF2Image AddedImage Added

Data serier i grafen er:

...

Ved at kigge i access loggen for notification broker under pull point testen, kan kald til notification broker ses.

GRAF2Image AddedImage Added

Data serier i grafen er:

...

Følgende tabel viser antal af pull point fordelt per iteration, hvor de er ligeligt fordelt med en meget lille afvigelse.

...

Udtræk omkring cpu fra denne log vises i de følgende grafer.

GRAF2Image AddedImage Added

Data serier i grafen er:

...

Udtræk omkring hukommelse og garbage collection fra denne log vises i de følgende grafer.

GRAF2Image AddedImage Added

Data serier i grafen er:

...

Udtræk omkring hukommelse, cpu netværkstrafik vises i følgende grafer.

Hukommelse:

GRAF2Image AddedImage Added

Data serier i grafen er:

...

Cpu og hukommelse procent:

GRAF2Image AddedImage Added

Data serier i grafen er:

...

Servicen viser et stabilt forbrug af hukommelse. Den envendte cpu er svagt stigende som servicen bliver presset.

Netværk:

GRAF2Image AddedImage Added

Data serier i grafen er:

• netIn (rød): den mængde data som er modtaget af containeren over netværket
• netOut (blå): den mænde mængde data som er sendt ud af containeren over netværket

TBDDe 2 grafer for ind- og udsendt data følges ad, hvilket er forventeligt; indkomne kald skaber trafik til database og kafka og igen retur til  kalder. netIn stiger mest. Dette kan måske skyldes kald til pullpoint, der ikke returner noget svar. Det indkomne kald fylder forholdsvis meget pga. security headeren og svarene er ret små med eller uden data.

Kafka statistik

De følgende grafer er lavet på baggrund af vmstat data på kafka serveren.

GRAF3Image AddedImage AddedImage Added

Data serier i grafen er:

...

Der er et meget svagt fald i Cpu Idle som testen skrider frem. Men den ligger meget højt generelt, så der er masser af cpu tid til rådighed.

GRAF3Image AddedImage AddedImage Added

Data serier i grafen er:

...

• Svartid per kald til servicen: 150 ms for 2 nodes og 5 tråde, og med et throughput på 53 kald per sekund
  Kravet er, at et kald gennemsnitlig må tage mindre end 5.000 ms med 1 kald på 20 pullpoints hvert 10. sekund. Dvs 2 per sekund. 
  Dette opfyldes så rigeligt, endda under øget belastning med flere nodes og tråde.
  Ingen af kald tager mindre mere end 10.000 ms.
  
  
• Cpu status: cpu forbruget konstant over test perioden. Det svinger inden for et interval og rammer kun ganske kort loftet.
  
  
• io på netværk: todo
  
  
• 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: Hverken disk skriv/læs eller cpu forbrug giver anledning til bekymring for om kafka serverne påvirker servicens performance negativt

Analysen af performance test data for pull point har ikke givet anledning til bekymring eller identificering af flaskehalse.