Page History

...

1. Svartiderne er målt via access loggen. Dermed er netværkstiden ikke med i resultatet.
2. Dette vil bleve vurderet med udgangspunkt i test resultaterne
3. Forudsætnigner
   1. NSP standard test framework vil blive brugt. Belasningen vil derfor lægge højere end 10 samtidige brugere. Der startes med 2 noder med 7 tråde. Dvs. 14 brugere., hvor belastningen gradvis øges fra 2 nodes og 7 tråde. Kravet med 10 samtidige brugere, der udfører et kald per sekund, kan omsættes til et throughput på 10 kald per sekund, hvilket kan vurderes vha. NSP test frameworkets output. 
   2. inden testen startes er en database med 50.000 allergier fordelt på 50.000 patiener klargjort
   3. de eksterne servicekald var aktiveret under kørslen. Da svartiderne for disse kan findes i log filerne kan der laves en beregning, der viser svartiderne uden de eksterne servicekald.
   4. der var ikke andet end performance testen, som kaldte noget på test systemet under testen
   5. der er ialt anvendt 4 søjler, hvor LAR og CAVE har kørt på alle 4.
   6. testen blev afviklet på hardware identisk til NSP produktionsmiljøerne

...

Performance testen er afviklet på følgende måde

• der Der er anvendt et test certifikat. Og der trækkes et idkort i setup fasen af testen, dvs hver gang en node startes på. Den del er holdt ude af performance målingen
• testen Testen er kørt på et test system opsat at Netic: cstag-lb.cnsp.netic.dk:8080  
• testen Testen er lavet i standard NSP performance frameworket (v.2.0.0), 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 test900, og den er den  kører 15 minutter per iteration.
• System under test (LAR og CAVE servicen) er kørt på på 4 docker containere
• Kald til de 3 eksterne service MSB har været aktiveret under testen

...

Da hverken LAR eller CAVE servicen skriver til disk selv, bliver io til disk ikke undersøgt. Der er ikke målinger på database serveren.

Disse undersøges Undersøgelserne foregår vha. de forskellige log filer, som er genereret under performance testen. De følgende afsnit gennemgår de vigtigste tal fra disse filer:

• JMeter log data belyser
  • Faktisk antal test iteration kørt
  • Throughput
  • (/stress01.nsp-test.netic.dk-lar/lar_listallergy_test900_stress01.nsp-test.netic.dk_master_20190513_114050.tar.gz.log)
• Access log og sla log (applikations server information) belyser
  • Antal kald per sekund
  • Svartid per kald
  • (Ex: docker01.cnsp.stage.nsp.netic.dk-lar/logs/lar/access.log)
• vmstat log (system information) belyser
  • cpu status
  • Logning sker hver 10. sekund
  • (Ex: docker01.cnsp.stage.nsp.netic.dk-lar/stats/docker01.cnsp.stage.nsp.netic.dk-cpu-20190513110936.log)
• jstat log (JVM information) belyser
  • Hukommelse (heap)   forbrug 
  • Garbage collection
  • Tidsstempel Der er tidsstempel per log linie
  • (Ex: docker01.cnsp.stage.nsp.netic.dk-lar/stats/docker01.cnsp.stage.nsp.netic.dk-cave-jstat-20190513110936.log)
• docker stats log (container information) belyser
  • Hukommelse
  • io på netværk
  • Der er ikke noget fast logningsinterval.
  • (Ex: docker01.cnsp.stage.nsp.netic.dk-lar/stats/docker01.cnsp.stage.nsp.netic.dk-cave-container-20190513110936.log)

...

Kravet til testen er, at der skal køres med 10 samtidige brugere med hver et kald per sekund. NSP's test framework fungerer med en bestemt belastning i testen som gradvis øges.   Testen har kørt i første iteration med 14 samtidige brugere, anden iteration har 20 samtidige brugere og sidste iteration 30 samtidige brugere. Hvilket I første iteration har testen kørt med 20 kald per sekund, hvilket ligger over kravet til testen. Da testen også har kørt med MSB servicene aktiveret, hvilket ikke er et krav, har det lagt yderligere pres på testen. 

Derfor konkluderes det, at , ud fra JMeter loggens data, er performance kravets forudsætning om 10 brugere med hver et kald per sekund så rigeligt overholdt.

Access log data

...

Desuden kan tidsforbruget for kald til MSB servicene findes via via servicenes sla logs (nsputil-sla-lar.log)  og messageid, og på den måde trækkes fra LAR servicens tid for at få netto tiden per kald. 

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 Http koden findes i access loggen (kald returnerede med fejl (500) eller ingen fejl(200)).

De beregnede data er antal kald, kald per sekund i gennemsnit (hver iteration er 900 sekunder) , samt tidsforbrug per kald i millisekunder. 

...

Udtræk af svartid og antal kald fordelt over testens løbetid vises i følgende 4 grafer. Svartiderne er uden MSB tidsforbruget:

Data serier i grafen er:

• DurationAverage (rød): den gennemsnitlige svartid (ms) for hvert minut (uden MSB kald)
• NoOfCalls (blå): det gennemsnitlige antal kald hvert minut
• De 3 iterationer (sort) er baseret på det tidstempel, som findes i jstatloggen

Vurdering

Af tabel og graferne grafer fremgår det, at jo flere brugere nodes og tråde (brugere disse øges per iteration) jo flere kald kommer der igennem per sekund. Tallene svarer overens med de tal JMeter kom frem til som throughput.

Det ses (tydligst i tabellen), at jo flere brugere nodes/tråde jo højere bliver svar tiden.  Performance kravet er 200 ms ved 10 brugere uden MSB services slået til. Ovenstående tabel viser, at ved 14 brugere ( iteration 1 ) er svartiden 155 ms, og tidligere fremgik det at througput her var 20 kald per sekund. Vi er inden for performance kravet.

...

• Svartid per kald til servicen: 155 ms for 14 brugere2 nodes og 7 tråde, og med et throughput på 20 kald per sekund
  Kravet er, at et kald skal tage mindre end 200 ms med 10 brugere der hvert har et kald per sekund
  Dette opfyldes, endda under øget belastning med flere brugere.
  Antal kald per sekund til servicen: 20,4 med 14 brugerenodes og tråde.
  
  
• Cpu status: for både LAR og CAVE  er cpu forbruget konstant over test perioden. Det svinger inden for et interval og rammer aldrig i nærheden af loftet.
  
  
• io på netværk: for både LAR og CAVE er der er en jævn strøm af læs og skriv via netværket
  
  
• Hukommelses forbrug: både LAR og CAVE håndterer brug af hukommelse fint
  
  
• Garbage collection: både LAR og CAVE 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.

...