Page History
...
- 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)).
...
Udtræk af svartid og antal kald fordelt over testens løbetid vises i følgende grafer:
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
Data serier i grafen er:
...
Udtræk omkring cpu fra denne log vises i de følgende grafer.
Data serier i grafen er:
...
Udtræk omkring hukommelse og garbage collection fra denne log vises i de følgende grafer.
Data serier i grafen er:
...
Udtræk omkring hukommelse, cpu netværkstrafik vises i følgende grafer.
Hukommelse:
Data serier i grafen er:
...
Cpu og hukommelse procent:
Data serier i grafen er:
...
Servicen viser et svagt stigende forbrug af hukommelse, men som skrevet for forrige graf anses det ikke som et problem. Den envendte cpu er stigende som servicen bliver presset.
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æ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 kafka og igen retur til kalder.
Vurdering
Intet at bemærke.
...
De følgende grafer er lavet på baggrund af vmstat data på kafka serveren.
Data serier i grafen er:
...
Der er et meget svagt fald i Cpu Idle som testen skrider frem. Men den ligger generelt højt, så der er masser af cpu tid til rådighed.
Data serier i grafen er:
...
Der er intet at bemærke som kan påvirke nas servicens performance i negativ retning.
Konklusion
...
Efter at have analyseres data fra performance testen kan følgende trækkes frem:
- 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 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.
| Pull point | iteration 1 | iteration 2 | iteration 3 | iteration 4 |
| pullPoint0001 | 1789 | 1790 | 1789 | 1790 |
| pullPoint0002 | 1789 | 1790 | 1789 | 1790 |
| pullPoint0003 | 1789 | 1790 | 1789 | 1790 |
| pullPoint0004 | 1789 | 1790 | 1789 | 1790 |
| pullPoint0005 | 1789 | 1790 | 1789 | 1790 |
| pullPoint0006 | 1789 | 1788 | 1789 | 1790 |
| pullPoint0007 | 1789 | 1790 | 1788 | 1790 |
| pullPoint0008 | 1789 | 1790 | 1788 | 1790 |
| pullPoint0009 | 1789 | 1790 | 1788 | 1790 |
| pullPoint0010 | 1788 | 1790 | 1788 | 1790 |
| pullPoint0011 | 1788 | 1790 | 1788 | 1790 |
| pullPoint0012 | 1788 | 1790 | 1788 | 1790 |
| pullPoint0013 | 1788 | 1790 | 1788 | 1790 |
| pullPoint0014 | 1788 | 1789 | 1788 | 1790 |
| pullPoint0015 | 1788 | 1789 | 1788 | 1790 |
| pullPoint0016 | 1788 | 1787 | 1788 | 1789 |
| pullPoint0017 | 1788 | 1789 | 1788 | 1790 |
| pullPoint0018 | 1788 | 1785 | 1788 | 1789 |
| pullPoint0019 | 1788 | 1789 | 1788 | 1789 |
| pullPoint0020 | 1788 | 1789 | 1788 | 1789 |
| Total | 35769 | 35785 | 35766 | 35796 |
...
- 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.
...
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.
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
...
Der er intet at bemærke som kan påvirke nas servicens performance i negativ retning.
Konklusion
Efter at have analyseres data fra performance testen kan følgende trækkes frem:
- 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.