...

• 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 servicene)
• NSP standard performancetest framework version 2.0.0

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.

Kommentarer

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

...

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

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 vha. de forskellige log filer, som er genereret under performance testen. De følgende afsnit gennemgår de vigtigste tal fra disse filer:

...

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 iteration14 iteration med 14 samtidige brugere, anden iteration har 20 samtidige brugere og sidste iteration 30 samtidige brugere. Hvilket ligger over kravet til testen. Da testen også har kørt med MSB servicen aktiveret servicene aktiveret, hvilket ikke er et krav, har det lagt yderligere pres på testen. 

Derfor konkluderes det at, ud fra JMeter loggens data ser testens resultat fornuftig ud i forhold til performance kraveter performance kravets forudsætning om 10 brugere så rigeligt overholdt.

Access log data

Denne log findes for hver applikations server (docker container) for både LAR og CAVE servicen.

...

De 4 dataserier i graferne er meget stabile. Man fornemmer aktivitet ser en aktivitet omkring start og slut af de 3 iterationer. Størst udsving er der ved opstart af testen, hvor den cpu der bliver brugt af applikationen (cpuNonKernel) striger stiger meget og idle cpu tilsvarende falder. Men det er kun kortvarigt.

Vurdering

Graferne ser fornuftige ud. Der er intet negativt at bemærke omkring cpu forbrugforbruget. 

Jstat log

Denne log findes for hver applikations server (docker container) - en for LAR og en for CAVE. Loggen viser resultatet af kommandoen jstat. Jstat siger noget om, hvordan JVM'en har det. 

...

Den yngre forbrugte hukommelse eskalerer ikke for hverken LAR eller CAVE. Garbage collecteren holder det i skakgør sit arbejde.

Docker stats log

Denne log findes for hver applikations server (docker container) - en for LAR og en for CAVE. Loggen viser resultatet af kommandoen docker stats. Docker stats siger noget om, hvordan containeren forbruger sine ressourcer.

...

De 2 grafer for ind- og udsendt data følges pæntad, hvilket er forventeligt

Vurdering

Placeringen af iterationernes markering kunne umiddelbart godt se forkert ud når man generelt ser på graferne. Der er ændret adfærd ca. 150 enheder før den angivne markering første gang, og den bliver længere og længere til venstre.

Derforuden...

Intet at bemærke.

Konklusion

Efter at have analyseres data fra performance testen kan følgende trækkes frem:

• Svartid per kald til servicen: 155 ms for 14 brugere
  Kravet var at et kald skal tage mindre end 200 ms
  Dette opfyldes, endda under øget belastning med flere brugere.
  
  
• Antal kald per sekund til servicen: 20,4 med 14 brugere
  
  
• Cpu status: for både LAR og CAVE  er cpu forbruget nogenlunde konstant 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 , hvilket holder forbruget af hukommelsen i skakog 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.

...