Scope

Performancetesten består af et antal kald til læsning af allergier for en liste af 50.000 personer (cpr numre). 

Testen involverer følgende komponenter

• LAR service som første led (v. 1.0.2)
• CAVE service som andet led (v. 1.0.2)
• FHIR database som tredie led (v. 3.7.0)
• Derforuden har integrationen til minlog, MinSpæring og behandler relation check være aktiveret under kørslen (Herefter benævnt som MSB)

Performance krav

Kravene fra fra kravspecifikationen lyder som følger:

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.

TODO: addresser hvert punkt: foreløbige noter:

1: kan vi tage talene uden netværk?

2: vurder

3a: find det sted hvor throughput er dette: 10 kald per sek

3b: inden testen startes er en database med 50.000 allergier fordelt på 50.000 patiener klargjort

3c: de eksterne servicekald var aktiveret under kørslen. Afhængig af udfald overvejes om en kørsel uden aktivernig er nødvendig.

3d: var dette tilfældet?

3e: ?er dette tilfældet på test

3f: går ud fra dette er tilfældet?

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

Se iøvrigt LAR test vejledning afsnit 2.3 performance test for detaljer.

Performance tal

(vedhæft filerne?)

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

Følgende punkter bliver derfor undersøgt:

• 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 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 ?50

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)

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

Det fremgår også af filen, at den endelige måling af throughput er 25,09 kald per sekund. ?2

Samt at fejlprocentet på den fulde kørsel er 0,01 %. 

Vurdering

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 med i første runde 14 samtidige brugere, anden runde 20 brugere og sidste runde 30 brugere. Hvilket ligger over kravet til testen. Da testen også har kørt med MSB servicen aktiveret har det lagt yderligere pres på testen. 

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

Access log data

For hver 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)

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. 

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.

Følgende tabel viser en række beregnede data fra access loggen fordelt på applikations server (container), testrunde og http kode. Testrunde er beregnet ved at sammenligne tidstempel fra access log med start og sluttidspunktet for runden. 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 runde er 900 sekunder), tidsforbrug per kald i millisekunder. 

Vurdering

Af tabellen fremgår det, at jo flere brugere (brugere øges per runde) jo flere kald kommer der igennem per sekund. 

Det ses også, 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 154 ms. Vi er inden for performance målet.

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.

Vmstat log

Konklusion

Fejlprocess vurdering,

tjek evt. de 500 kald, hvorfor de optod