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:
...
Man kan se at cpuIdle og cpuNonKernel påvirkes som servicen presses mere. cpuIdle svinger oftere mod 0 i de sidste 2 iterationer. Det er dog vigtigt at bemærke at det kun er kortvarigt og cpyIdle cpuIdle går op igen.
Vurdering
Der er intet negativt at bemærke omkring cpu forbruget.
...
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
Pull Point
Scope
Performance testen består af en række kald til læsning af pull points.
Testen involverer følgende komponenter
- NAS 2 Pull Point service version 2.0.6
- NAS 2 Notification Broker service version 2.0.6 (baggrundsbelastning)
- NSP kafka
- Gallera MariaDB cluster
- NSP standard performance test framework version 2.0.10
Performance krav
Performancekravene er som følger:
- Forudsætninger:
- Baggrundsdata:
- 1 topic
- 1.000 pullpoints på dette topic (20 af disse bruges aktivt under testen)
- Hver pullpoint har en unik idliste med hver 3000 id'er
- Der behøver ikke være beskeder på tipic inden testen starter
- Baggrundsbelastning
- Notifikation broker skal lave 40 adviseringer per sekund fordelt ligeligt på 20 udvalgte pullpoints
- Dvs. 2 adviseringer per pullpoint per sekund
- Test: 1 kald til getMessage på hver af de 20 udvalgte pullpoints hver 10. sekund. Dvs. 2 kald per sekund
- Baggrundsdata:
- Krav:
- Gennemsnitlig svartid skal være under 5.000 millisekunder
- 95 % skal være under 10.000 millisekunder
- 99 % skal være under 20.000 millisekunder
Kommentarer til forudsætninger og krav
- Forudsætninger
- De omtalte baggrundsdata er til stede i form af et database script, der er indlæst inden opstart af test
- Baggrundsbelastningen er til stede i form at et baggrundsjob der skriver til Notification broker
- Som for notification broker testen anvendes NSP standard framework, hvor et throughput på 2 kald per sekund kan vurderes
- Krav til svartider vil blive vurderet med udgangspunkt i test resultaterne.
Afvikling
Performance testen er afviklet på følgende måde
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.
Testen involverer følgende komponenter
- NAS 2 Pull Point service version 2.0.6
- NAS 2 Notification Broker service version 2.0.6 (baggrundsbelastning)
- NSP kafka
- Gallera MariaDB cluster
- NSP standard performance test framework version 2.0.10
Performance krav
Performancekravene er som følger:
- Forudsætninger:
- Baggrundsdata:
- 1 topic
- 1.000 pullpoints på dette topic (20 af disse bruges aktivt under testen)
- Hver pullpoint har en unik idliste med hver 3000 id'er
- Der behøver ikke være beskeder på tipic inden testen starter
- Baggrundsbelastning
- Notifikation broker skal lave 40 adviseringer per sekund fordelt ligeligt på 20 udvalgte pullpoints
- Dvs. 2 adviseringer per pullpoint per sekund
- Test: 1 kald til getMessage på hver af de 20 udvalgte pullpoints hver 10. sekund. Dvs. 2 kald per sekund
- Baggrundsdata:
- Krav:
- Gennemsnitlig svartid skal være under 5.000 millisekunder
- 95 % skal være under 10.000 millisekunder
- 99 % skal være under 20.000 millisekunder
Kommentarer til forudsætninger og krav
- Forudsætninger
- De omtalte baggrundsdata er til stede i form af et database script, der er indlæst inden opstart af test
- Baggrundsbelastningen er til stede i form at et baggrundsjob der skriver til Notification broker
- Som for notification broker testen anvendes NSP standard framework, hvor et throughput på 2 kald per sekund kan vurderes
- Krav til svartider vil blive vurderet med udgangspunkt i test resultaterne.
Afvikling
Performance testen er afviklet på følgende måde
- Testen er kørt på et test system opsat at Netic
- Testen er lavet i standard
- Testen er kørt på et test system opsat at Netic
- Testen er lavet i standard NSP performance frameworket (v.2.0.10), udviklet af Arosii i JMeter.
- Der er kørt en testplan med stadig øget belastning ved at øge antallet af tråde og noder indtil det målte throughput ikke længere vokser med tilsvarende mængde.
- Testplanen, der er kørt, er pptest900, og den kører 15 minutter per iteration.
- System under test er kørt på på 2 docker containere
- Den anvendte kafka har kørt på 3 docker containere
...
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.
| 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 |
...
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:
...
- 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
...
De 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 følgende grafer er lavet på baggrund af vmstat data på kafka serveren.
...
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 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.
Derudover kan nævnes, at de 3 kald der gik galt under testen og returnerede http 500, fejlede pga. manglende svar fra en af de 3 MSB service kald: Service Unavailable.
...
- Baggrundsbelastning
- Notifikation broker skal lave 40 adviseringer per sekund fordelt ligeligt på 20 udvalgte pullpoints
- Dvs. 2 adviseringer per pullpoint per sekund
- Test: 1 kald til getMessage på hver af de 20 udvalgte pullpoints hver 10. sekund. Dvs. 2 kald per sekund
- 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.
...