...

1. Systemets svartider måles på en klient i umiddelbar nærhed af LAR service snitfladen, således at der medregnes et netværkskald mellem klient og service.
2. Systemets gennemsnitlige svartid ved læsning skal ligge under 200ms.
3. Forudsætninger for ovenstående svartider er, at:
   1. systemet anvendes af 10 samtidige brugere, der udfører et kald pr. sekund med 1000ms tidsmæssig forskydning på forskellige CPR numre.
   2. databasen indeholder 50.000 allergi-registreringer på et tilsvarende antal patienter.
   3. eksterne servicekald er deaktiveret
   4. der er ikke andre services der anvender infrastrukturen.
   5. der anvendes to applikationsservere til hver service, svarende til en NSP med to søjler til LAR servicen og to Back-End servere til CAVE servicen. Servicekald fordeles efter Round-Robin princippet mellem hver af de to servere.
   6. Serverne er hardwaremæssigt konfigureret svarende til NSP applikationsservere.

Kommentarer

1. ???
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.
   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. ???
   5. der er ialt anvendt 4 søjler, hvor LAR og CAVE har kørt på alle 4.
   6. ???

Afvikling

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

• 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 er kørt på test system opsat at Netic: cstag cstag-lb.cnsp.netic.dk:8080  
• 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 kører 15 minutter per iteration.
• System under test (LAR og CAVE servicen) er kørt på på 4 docker containere, fordelt ligeligt på 2 fysiske maskiner (?1)
• Kald til de 3 eksterne service MSB har været aktiveret under testen

...

Udover det fremsatte performance mål krav med en svartid på under 200 ms, er der en række andre punkter som bør analyseres for at vurdere servicens sundhed.

...

• Svartid per kald
• Antal kald per sekund
• Cpu status
• io på netværk ?50
• Hukommelses forbrug
• Garbage collection

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

• JMeter log data belyser
  • Faktisk test runder kørt
  • Throughput
• Access log og sla log (applikations server information) belyser
  • Antal kald per sekund
  • Svartid per kald
• vmstat log (system information) belyser
  • cpu status
• jstat log (JVM information) belyser
  • Hukommelse (heap)  forbrug 
  • Garbage collection
• docker stats log (container information) belyser
  • Hukommelse
  • io på netværk

JMeter log data

JMeter hoved filen beskriver overordnet testens resultet.

...

• • (/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 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
  • Logning sker hvert sekund
  • (Ex: docker01.cnsp.stage.nsp.netic.dk-lar/stats/docker01.cnsp.stage.nsp.netic.dk-cave-container-20190513110936.log)

Hver kørsel/runde (øgning af belastning) har en start og slut tid. Filerne access.log og jstat.log indeholder tidstempler. Dette muliggør at de kan mappes til en given runde. Filerne vmstat og docker stats har ikke tidstempler. Men da disse er startet samtidig med jstat loggen og logintervallet er kendt, kan runderne placering i data beregnes.

JMeter log data

JMeter hoved filen beskriver overordnet testens resultet._listallergy_test900_stress01.nsp-test.netic.dk_master_20190513_114050.tar.gz.log)

Her kan  kan ses, at der er kørt 3 runder med test, deres tidsinterval og throughput for hver.

...

Derfor konkluderes at ud fra JMeter loggens data ser testens resultat fornuftig ud i forhold til performance måletkravet.

Access log data

For hver applikations server (docker container) er der en access log for både LAR og CAVE servicen.(Ex: docker01.cnsp.stage.nsp.netic.dk-lar/logs/lar/access.log)) er der en access log for både LAR og CAVE servicen.

Her findes data for hvert enkelt kald, der er lavet til de 2 LAR og CAVE services, herunder hvor lang tid et kald har taget (Duration). Ved at kigge på de kald, der er foretaget til LAR servicen kan den gennemsnitlige tid et kald tager beregnes. 

...

Det ses, at jo flere brugere 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 (runde 1) er svartiden 155 ms. Vi er inden for performance måletkravet.

Man kan undres over, hvorfor det skal tages så meget mere tid når MSB servicene medtages. Det har vist sig at kaldet til BRS er lavet uhensigtmæssigt, hvilket bliver rettet på Jira CAVE-78. Dette burde give bedre performance.

...

For hver applikations server (docker container) findes der en log, som viser resulatet af kommandoen vmstat. Kommandoen er kørt hver 10. sekund.(Ex: docker01.cnsp.stage.nsp.netic.dk-lar/stats/docker01.cnsp.stage.nsp.netic.dk-cpu-20190513110936.log)kommandoen vmstat. Kommandoen er kørt hver 10. sekund.

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

...

For hver applikations server (docker container) findes der 2 logge, som viser resulatet af kommandoen jstat. En for LAR og en for CAVE. Jstat siger noget om, hvordan JVM'en har det. (Ex: docker01.cnsp.stage.nsp.netic.dk-lar/stats/docker01.cnsp.stage.nsp.netic.dk-cave-jstat-20190513110936.log)hvordan JVM'en har det. 

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

...

[hvad kan man udlede af heapC???]

Vurdering

Den forbrugte hukommelse eskalerer ikke for hverken LAR eller CAVE.

...

For hver applikations server (docker container) findes der 2 logge, som viser resulatet af kommandoen docker stats. En for LAR og en for CAVE. Kommandoen er kørt hvert sekund. Docker stats siger noget om, hvordan containeren forbruger sine ressourcer.(Ex: docker01.cnsp.stage.nsp.netic.dk-lar/stats/docker01.cnsp.stage.nsp.netic.dk-cave-container-20190513110936.log)

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

...