UFYLDESTGØRENDE! Der har hidtil ikke være en tilfredsstillende testkørsel. 

Dette dokument dækker udførslen af en del af SCES performance testen. Se også Performance rapport - Generelt for  for generelle aspekter omkring testen. 

...

SCES, Stamdata CPR Enkeltopslags Servicen, bruges til at hente informationer fra bla. CPR registreret ud. Servicen har et antalt web services, som har forskellig funktionalitet. . i denne test er det operationerne "GetPersonDetails" og "DetGodeCPROpslag" der anvendes.

SCES er del af SDM leverancen. Til testen er SDM version 3.5.8 blevet brugt. 

Antagelser og forbehold

Det er ikke lykkes at få et tilfredsstillende resultat fra nogen af de kørsler, der er foretaget. Derfor er denne rapport baseret på den seneste kørsel.

• Begrænset Begrænset delmængde af datasættet. Som det beskrives senere så testet ikke med alle mulige CPR numre, men med mindre delmængde. Valget her er baseret på udhentning via SKRS. Dette kan påvirke hvor hurtigt databasen tilbyder data.
• Lokalt netværk: Alle kald til SKRS sker via et et lokalt netværk der  der er betydeligt hurtigere end hvad man kan forvente anvendersystemer har adgang til. Dette vil samlet set betyde en længere svartid pr forespørgelse, men burde ikke påvirke TP synderligt.

...

Testplaner anvendt i denne performance test: personlookup

Testplanen personlookup består  består af 2 dele, først en opsætningsdel der ikke tælles med i testen og derefter et antal kald til SCES servicen. Opsætningsdelen består i at få signeret et id-kort og derefter hente op til 25.000 personer ud fra SDM via SKRS. Selve testen består i at hente persondetaljer for et antal tilfældigt udvalgte personnumre. For hver gennemløb af i testen hentes der persondetaljer på følgende måder:

• X ud af 100 gange hentes data gennem "DetGodeCPROpslag v. 1.0.2"
  • A ud af 100 gange hentes der personoplysninger inklusiv oplysninger om egen læge
  • B ud af 100 gange hentes der personoplysninger uden oplysninger om egen læge
• Y ud af 100 gange hentes data gennem "DetGodeCPROpslag v. 1.0.0"
  • A ud af 100 gange hentes der personoplysninger inklusiv oplysninger om egen læge
  • B ud af 100 gange hentes der personoplysninger uden oplysninger om egen læge
• Z ud af 100 gange hentes data gennem "GetPersonDetails"
  • 1 ud af 4 gange hentes
  Hent
  • en enkelt person baseret på personnummer.
  Hent 10
  • 1 ud af 4 gange hentes 10 personer baseret på personnumre.
  Hent et
  • 1 ud af 4 gange hentes et antal personer baseret på navn.
  Hent et
  • 1 ud af 4 gange hentes et antal personer baseret på fødselsdag.

Hvert gennemløb foretager disse 4 opslag i tilfældig rækkefølgeforetages N gange.

Fordeling

Fordelinger anvendt i denne performance test:test prod.

Fordelingen test foretager 250 af hver af de 4 forskellige opslag, hvilket giver 1000 kald til SCESprod foretager 2000 (N) gennemløb af testplanen, 99% (X) opslag mod "DetGodeCPROpslag v. 1.0.2", 0.5% (Y) opslag mod "DetGodeCPROpslag v. 1.0.0" og 0.5% (Z) opslag mod "GetPersonDetails". 90% (A) af opslag mod "DetGodeCPROpslag" sker med information om egen læge og 10% (B) uden.

Disse fordelinger er baseret på observationer af produktion i en tilfældig uge (24. marts 2014 til 31. marts 2014)

Målinger

Throughput

De kørsler af performance testen har givet de TP der kan ses i tabellen nedenunder. Uder over TP vises også hvor mange tråde og noder der skulle til for at opnå dette TP. Derudover er fejlraten her medtaget, da denne udgør i en tidligere test udgjorde en betydelig andel. 

Miljø

• CPU: dette er ikke den CPU ser ikke ud til at være en begrænsende faktor. På grafen ses en maksimal belast på cirka 60% på begge søjler. Det formodes at tiden bruges i databasen.at der i store dele af testen, er en belastning på mellem 80% og 90% på begge søjler, 100% belastning rammes kun en enkelt gang under forløbet.
• Heap: På vedhæftede graf er der intet andet usædvanligt at bemærke end normalt idle opførsel af en JVM applikation. Dermed har . Det vurderes at hverken GC tid eller størrelse af heap har nogen speciel indvirkning på TP.

Observerede fejl

 De ca 0.04% fejl der er i hver gennemløb af testen udgør så lille en fejlrate at de ikke kan have haft en indvirkning på TP.

Konklusion

Pga. fejlraten laves der ikke nogen sammenligning med faktisk brug. 

Da fejlraten er forholdsvis lav og ikke stiger med belastningen er det vores konklusion at der kan ses bort fra disse fejl i forhold til at vurdere på performance af SCES.

I Vedhæftet ses produktionsanvendelse i en tilfældig uge (2.-8.dec 2013). 24. marts 2014 til 31. marts 2014) blev der foretaget 451.335 forespørgelser med et anormalt peak den 25. mar kl. 11 på omkring 22.000 kald i timen.

Med det målte TP bliver det 756.000 forespørgelser i timen. I den undersøgte tid udnyttes servicen dermed maksimalt med 2.91%

Forbedringer

• Antallet af søjler kan  kan forøge TP. Dette er baseret på viden om at servicen agere uafhængigt af andre søjler. 

...