...

De beregnede data er antal kald, kald per sekund i gennemsnit (hver iteration er 900 sekunder) samt , gennemsnitlig tidsforbrug per kald i millisekunder samt antal kalder større eller lig med 500 millisekunder. 

Udtræk af svartid og antal kald fordelt over testens løbetid vises i følgende grafer:Image RemovedImage Removed

Data serier i grafen er:

...

Det ses (tydligst i tabellen), at jo flere nodes/tråde jo højere bliver svar tiden.  Performance kravet er under 250 ms i gennensnit ved 10 adviseringer per sekund. Ovenstående tabel viser, at ved iteration 1 er svartiden 9 ms, og tidligere fremgik det at througput her var 400 kald per sekund. Vi er inden for performance kravet.

Tabellen ovenfor viser også, at det antal kald der tager mere end 500 ms er så lavt, at kravet om 95 % skal være under 500

...

ms er overholdt. 

Vi er inden for performance kravene.

Pull Point

Scope

Performance testen består af en række kald til læsning af pull points.

...

Derfor konkluderes det, at ud fra JMeter loggens data, er performance kravets forudsætning om 2 kald så rigeligt overholdt.

Baggrundsbelastning

TODO

Access log data

Denne log findes for hver applikations server (docker container).

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

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

De beregnede data er antal kald, kald per sekund i gennemsnit (hver iteration er 900 sekunder), gennemsnitlig tidsforbrug per kald i millisekunder samt antal kalder større eller lig med 500 millisekunder.  

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
• NoOfCalls (blå): det gennemsnitlige antal kald hvert minut
• Iterationer (sort) er baseret på det tidstempel, som findes i loggen

Vurdering

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

Det ses (tydligst i tabellen), at jo flere nodes/tråde jo højere bliver svar tiden.  Performance kravet er under 250 ms i gennensnit ved 10 adviseringer per sekund. Ovenstående tabel viser, at ved iteration 1 er svartiden 9 ms, og tidligere fremgik det at througput her var 400 kald per sekund.

Tabellen ovenfor viser også, at det antal kald der tager mere end 500 ms er så lavt, at kravet om 95 % skal være under 500 ms er overholdt. 

Vi er inden for performance kravene.

**

1. Forudsætninger:
   1. Baggrundsdata:
      1. 1 topic
      2. 1.000 pullpoints på dette topic (20 af disse bruges aktivt under testen)
      3. Hver pullpoint har en unik idliste med hver 3000 id'er
      4. Der behøver ikke være beskeder på tipic inden testen starter
   2. Baggrundsbelastning
      1. Notifikation broker skal lave 40 adviseringer per sekund fordelt ligeligt på 20 udvalgte pullpoints
      2. Dvs. 2 adviseringer per pullpoint per sekund
   3. Test: 1 kald til getMessage på hver af de 20 udvalgte pullpoints hver 10. sekund. Dvs. 2 kald per sekund
2. Krav:
   1. Gennemsnitlig svartid skal være under 5.000 millisekunder
   2. 95 % skal være under 10.000 millisekunder
   3. 99 % skal være under 20.000 millisekunder