...

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

...

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

...

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

...

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